Les fondamentaux de la gestion de projet

Le partenaire de référence
des entreprises dans la définition, la mise en œuvre
et le pilotage de leur transformation digitale
PRÉSENTATION DU GROUPE – JUILLET 2014

SQLI GROUP
DIGITAL PERFORMANCE LEADER
+ CA 154 M€ en 2013 (na)
+ CAC 40 : Sqli accompagne 3 entreprises sur 4
+ Coté sur NYSE Euronext Paris (SQI)
5AGENCESDIGITALES
2CENTRESOFFSHOREMAROC
1CENTRENEARSHORE BORDEAUX
1800TALENTS
PAYS6
PARISLYONBORDEAUXNANTESROUENTOULOUSELILLEAIX-EN-PROVENCE
SUISSEBELGIQUELUXEMBOURGPAYS-BAS
MAROCFRANCE
100%TECHNOLOGIES
DIGITALES

Le pionnier de l’innovation
Et de l’industrialisation digitale
NOTRE DOUBLE RÉPONSE
POUR RÉUSSIR
LA TRANSFORMATION
DIGITALE
BOOSTERLES VENTES
& L’EXPÉRIENCE CLIENT
CONSEIL – MARKETING - SOLUTIONS
TRANSFORMER
LES ORGANISATIONS & SYSTÈMES
CONSEIL – TECHNOLOGIES - INDUSTRIALISATION
1ère agence digitale intégrée
Data marketing & Commerce connecté

COMMERCE
CONNECTÉ
DIGITALISATION
DES OPÉRATIONS
LE SI CROSS-CANAL
& MOBILE
ENTREPRISE
COLLABORATIVE
INNOVATION
BUSINESS
EXPÉRIENCE
CLIENT
VENTES &
RELATION
CLIENT
ENTREPRISE
DIGITALE
CRÉER
LA PERFORMANCE
DIGITALE

5
Clients clés
EXPERTISES DÉDIÉES
BANQUE FINANCE ASSURANCE / COMMERCE & DISTRIBUTION
AÉROSPATIAL & DÉFENSE / TOURISME & TRANSPORT
4ILS NOUS FONT CONFIANCE

Ch.Dessus
Janvier 2015
LES BASIQUES DE LA GESTION DE
PROJET

SOMMAIRE
+ 0. DÉFINITIONS
+ 1. MODE PROJET
+ 2. ENJEUX ET OBJECTIFS DU PROJET
+ 3. PARTIES PRENANTES
+ 4. AMÉLIORER LES PRATIQUES
+ 5. CADRER LE PROJET
+ 6. DÉMARCHE DE PILOTAGE ET
CONDUITE DE PROJET
+ 7. FOCUS SUR LES DÉMARCHES
AGILES ET ITÉRATIVES
9Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+ 8. GOUVERNER LE PROJET
+ 9. COMPRENDRE LES BESOINS.
STRUCTURER LA SOLUTION
+ 10. STRUCTURER LES ACTIVITÉS ET
LIVRABLES
+ 11. EVALUER LA CHARGE (EFFORT)
+ 13. CONSTRUIRE LE PLANNING
(CALENDRIER)
+ 12. PLAN PROJET : FAIRE LA SYNTHÈSE DE
SON PROJET

SOMMAIRE
+ 14. CONSTITUER SON ÉQUIPE ET
GÉRER LES RESSOURCES
HUMAINES
+ 15. GÉRER LES CONFLITS
+ 16. MAÎTRISER LES RISQUES DU
PROJET
+ 17. BILAN DU PROJET
+ 18. FACTEURS CLÉS DU SUCCÈS

DÉFINITIONS
11
L’ESSENTIEL
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
0.

DÉFINITIONS
+PROJET
+PROGRAMME – PORTEFEUILLE DE
PROJETS – CHANTIER - ACTIVITÉ
+RACI
+PROCESSUS
+CYCLE DE VIE
+ITÉRATION
+LIVRABLE
+JALON

PROJET
+ AFNOR
Un projet se définit comme une démarche spécifique, qui permet de structurer méthodiquement et
progressivement une réalité à venir.
+ ISO 10006
Le projet est un processus unique qui consiste en un ensemble d'activités coordonnées et maîtrisées,
comportant des dates de début et de fin, entrepris dans le but d'atteindre un objectif conforme à des
exigences spécifiques, incluant des contraintes de délais, de coûts et de ressources.
+ PROJECT MANAGEMENT INSTITUTE
Un projet est une entreprise temporaire visant à créer un livrable (produit ou service) unique
+ AFITEP (ASSOCIATION FRANCOPHONE DU MANAGEMENT DE PROJETS)
Le projet est un ensemble d'actions à réaliser avec des ressources données, pour satisfaire un objectif
défini, dans le cadre d'une mission précise, et pour la réalisation desquelles on a identifié non
seulement un début, mais aussi une fin.
13
DÉFINITION

PROJET
+ OBJECTIF
Périmètre
Critères de réussite
+ BUDGET
€ $ £
jours/homme
+ DÉLAIS
Contraintes de planning
Date butoire (ex : 1er Janvier 2000)
+ RESSOURCES
Équipe, Machines, Environnement
Plan de charge, répartition de l’effort et des ressources dans le temps
14
QUATRE MOTS DÉFINISSENT UN PROJET

PROJET
+ PAR NATURE LE PROJET A DES CARACTÉRISTIQUES PARTICULIÈRES
» Il comporte une dimension novatrice : fonctionnelle, technique, processus,
organisation…
» Il est non répétitif avec une organisation spécifique dédiée par nature
temporaire
» Il a un début et une fin qui lui sont propres
» Un bilan du projet est fait à la fin de celui-ci et non forcément annuellement
» Il est tourné vers l'objectif final : le produit dans le domaine l’ingénierie,
l’organisation
» Un projet doit s’adapter et donc être capable de supporter des modifications
fréquentes
» Il doit équilibrer les contraintes techniques, de coût et de délais
15
CARACTÉRISTIQUES

LIVRABLE
+ DÉFINITION DU TERME « LIVRABLE »
Tout ce qui est produit par le projet
Généralement un livrable correspond à la réalisation d’un engagement du projet. Il est réalisé au cours
d’une étape / phase.
» La qualité intrinsèque d’un livrable doit être vérifiée
» Le respect des processus de réalisation des livrables sont contrôlées : respect des règles
(éthiques, sécurité, sureté, réglementation) et respect des processus et démarches internes
(normes internes).
+ EXEMPLE DE LIVRABLES
Note d’opportunité, lettre de mission, note de cadrage, étude, rapport, plan de projet, cahier des
charges, spécifications
Plan recette, Plan de déploiement, expérimentation, intégration, compte rendu de recette
Notes de procédures
Logiciel, packages, équipements, automates
Description d’une organisation, processus
Plan de formation, manuels de formation
…
16
DÉFINITION

JALON
+ Point de référence qui marque un événement principal dans un projet et qui est utilisé
pour suivre son avancement.
+ Engagement fort, éventuellement intégré à un contrat. Le jalon est modifiable sous
condition d’accord du client et du fournisseur.
Remettre en cause un jalon peut signifier remettre en cause l’atteinte d’un objectif majeur du
projet et donc l’atteinte des enjeux du projet et donc le projet.
+ Les jalons servent à planifier les activités du projet
+ Les jalons marquent les enchaînements de phases du projet. Souvent liés à un comité de
pilotage qui va acter le passage de Jalon : fin d’une étape et lancement de l’étape
suivante.
+ Dans le cadre du contrat, le jalon est lié à la signature d’un PV (procès verbal) avec une
facturation.
17
DÉFINITION

CYCLE DE VIE
+UN CYCLE DE VIE EST UN ENCHAINEMENT DE PHASES, ÉTAPES QUI
STRUCTURENT L’ACTIVITÉ
+TOUTE MÉTHODOLOGIE DE GESTION DE PROJET EST CONSTRUITE AUTOURS
D’UN CYCLE DE VIE :
› ENCHAINEMENT DE PHASES ET ÉTAPES QUI PEUVENT ÊTRE
PLANIFIÉES ET COORDONNÉES.
18
DÉFINITION

ITÉRATION
+ UNE ITÉRATION C’EST LE FAIT DE RÉPÉTER UNE PHASE OU UN ENSEMBLE DE PHASES
D’UN PROJET.
+ UNE ITÉRATION PEUT ÊTRE LONGUE : 2 À 4 MOIS OU TRÈS COURTE : QUELQUES
JOURS.
+ UNE ITÉRATION EST ELLE-MÊME CONSTITUÉE D’ACTIVITÉS QUI S’ENCHAINENT POUR
PRODUIRE UN RÉSULTAT.
Les activités d’une itération peuvent elles même être itérées.
19
DÉFINITION

MATRIOCHKA
20
PROGRAMME – PORTEFEUILLE DE PROJETS – PROJET – CHANTIER- ACTIVITÉ
Programme
Projet
Chantier
Activité
Ensemble structuré de projets qui
permettent à une organisation
d’atteindre les objectifs du programme
Composant d’un programme ayant
un objectif clair
Composant d’un projet ayant des
livrables clairement identifiés

PROCESSUS
+PROCESSUS : Ensemble structuré d’activités pour accomplir un objectif précis.
Un processus utilise un ou plusieurs inputs (entrées) et les transforment en
outputs (produits ou services en sortie).
› Un processus produit toujours quelque chose. Un processus qui ne produit rien
ne sert à rien.
› Exemple de sorties : validation, revue, document, produits fabriqués…
Commande validée, volume de production, spécification détaillée… etc…
+ RESULTAT : ce que produit une activité dans un processus ou en fournissant un service.
Le terme est utilisé pour parler des résultats attendus et des résultats réels (constatés)
» Outcome : Bénéfice, gain ou au contraire perte
» Output : Sortie du processus, Résultat (calcul, mesure d’un poids…), Service ou Produit
21
DÉFINITION

PROCESSUS
+ ACTIVITÉS
Décomposition du processus en unité de travail. Chaque activité est réalisée par un et un seul rôle.
+ RÔLES
Ensemble de responsabilités confiées à une personne. Ce n’est ni un poste, ni un emploi
+ INPUT OU TRIGGER
Données en entrée et Déclencheur
+ OUTPUT
Ce que produit un processus, une activité
+ TÂCHES
Décomposition d’une activité en unités de travail plus petites
+ PROCÉDURES ASSOCIANT DES TÂCHES À DES OUTILS, INFORMATIQUES, INDUSTRIELS OU MANUELS.
Décrire comment est effectuée la tâche
+ UN PROCESSUS EST TOUJOURS DOCUMENTÉ
A minima, on décrit les objectifs du processus, son périmètre, les inputs et les outputs.
22
COMPOSANTS DU PROCESSUS

PROCESSUS
+ UN PROCESSUS RÉPOND TOUJOURS À UN
OBJECTIF CLAIREMENT EXPRIMÉ
+ UN PROCESSUS SE DÉCOMPOSE EN PROCESSUS
OU EN ACTIVITÉS
Macro-processus
Processus opérationnels, support, pilotage
+ UN PROCESSUS EST TOUJOURS SIMPLE
pas plus de 4 à 5 activités et pas plus de 2 à 3 rôles
23
UN FORMALISME TRÈS SIMPLE
© SQLI GROUP – 2014 chdessus@sqli.com
UN PROCESSUS = UNE HISTOIRE COURTE
AVEC UN SEUL MESSAGE ET UNE CHUTE
!
+ ON NE CHERCHE JAMAIS L’EXHAUSTIVITÉ
+ TROP DÉTAILLÉ  TROP COMPLIQUÉ  MESSAGE BROUILLÉ  INUTILE
Un processus donne une vision générale, globale
Le détail est donné par les procédures
Décembre 2014

PROCESSUS
+UN PROCESSUS
Décrit le QUOI (activités) et QUI (rôles),
jamais le comment
Fait apparaître les risques, indicateurs, livrables
+UNE PROCÉDURE, MÉTHODE,
INSTRUCTION
Enchainement des tâches et utilisation des
outils et méthodes de travail
Décrit le COMMENT
Ne concerne qu’un seul acteur et une seule
activité
Fait apparaître les outils utilisés, indicateurs et
livrables
24
UN FORMALISME TRÈS SIMPLE
© SQLI GROUP – 2014 chdessus@sqli.com Décembre 2014

PROCESSUS
+ UN PROCESSUS EST PILOTÉ, SUIVI PAR DES INDICATEURS VISANT À CONTRÔLER SA
« PERFORMANCE »
Est-ce que le processus produit le résultat attendu : livrable, objectif…?
Est il efficace ?
Est il efficient ?
+ INDICATEURS :
Contrôler son usage, la conformité des pratiques au processus établi
 Audit de processus
Contrôler son efficacité et son efficience
 Audit de résultat
25
MESURER LA PERFORMANCE D’UN PROCESSUS

PROCESSUS
+ UN PROCESSUS N’EST JAMAIS FIGÉ.
+ UN PROCESSUS DOIT S’ADAPTER EN
PERMANENCE SELON UN PROCESSUS
D’AMÉLIORATION CONTINUE
Vérifier et améliorer son efficacité et son
efficience.
+ EFFICACITÉ
› Atteinte de l’objectif
+ EFFICIENCE
› Atteinte de l’objectif au meilleur coût, en
consommant le moins de ressources
possibles
› Démarche « LEAN » d’amélioration
continue pour éliminer les temps
d’attente et les boucles inutiles.
26
AMÉLIORATION CONTINUE
Source : hakanforss.wordpress.com

RÔLES ET RACI
+ R : RESPONSIBLE  Celui qui fait  Réalisateur
+ A : ACCOUNTABLE  Celui qui valide ou contrôle  Autorité
+ C : CONSULTED  Contributeur
+ I : INFORMED  Informé du résultat
+ GÉNÉRALEMENT ON NE REPRÉSENTE QUE LE R ET LE A
+ MAXIMUM :
› UN ET UN SEUL A
› MOINS DE 3R POUR UN PROCESSUS
› PAS D’ACTIVITÉ PORTÉE PAR PLUSIEURS R. DANS CE CAS ON CRÉE UN RÔLE
SPÉCIFIQUE QUI REGROUPE LES R.
Exemple : comité de…
27
DÉFINITION

MODE PROJET
1.

POURQUOI LE MODE PROJET ?
+ LE MODE PROJET RÉPOND À DES ENJEUX DE SURVIE D’UNE ORGANISATION
Capacité à s’adapter dans un environnement en constante évolution et imprévisible
+ CONTRAINTES QUE L’ENVIRONNEMENT FAIT PESER SUR LES ORGANISATIONS
Complexité (en constante augmentation),
Incertitude (croissante),
Délais (de plus en plus courts),
Coûts (à maitriser)
+ LE MODE PROJET EST UNE RÉPONSE À L’ACCÉLÉRATION DES CHANGEMENTS DE
L’ENVIRONNEMENT
Une révolution culturelle dans les années 1980-1990
Un mode de pensée qui influence le management des organisations
L’orientation actuelle est la mise en œuvre d’organisations « agiles » : du changement par à coup
au changement érigé en principe de fonctionnement.
29
UNE RÉPONSE AU CHANGEMENT

ORGANISATION MATRICIELLE
+ DIFFICULTÉS DU MODE PROJET
Effet tunnel, changements par « à-coups », pouvant être perçus comme violents
Contrôle : financier, ressources affectées, délais
Objectifs : le projet est créé autours d’objectifs qui ne sont plus ceux du reste de
l’organisation
Déploiement, conduite du changement. En France, les obligations de
communication légales des changements majeurs figent le processus de
conduite du changement.
+ NOUVELLES VISIONS
Changement permanent, érigé en principe d’organisation
Organisations agiles, en adaptation permanente
Organisations par processus avec des équipes autocontrôlées autours du
responsable de processus
Intégrant les principes d’amélioration continue et d’analyse de la valeur.
Les équipes opérationnelles sont porteuses des améliorations.
Exemple : http://scaledagileframework.com/
30
1980 – 201X : ORGANISATIONS FONCTIONNELLES INTÉGRANT LE MODE PROJET
Développement de centres de
services axés sur un ou plusieurs
processus majeurs dont ils assurent
la responsabilité : manager du
processus

ORGANISATION AGILE
31
SCALED AGILE FRAMEWORK (SAFe)
Source :
http://scaledagileframework.com
/downloads/

ENJEUX DU PROJET
Story-telling « Au bonbon d’autrefois »
2.

STORY-TELLING
+EN COURS DE FORMATION, VOUS SEREZ SENSIBILISÉS AU
TRAVERS D’UNE SAGA FAMILIALE :
La société « Au bonbon d’autrefois »
33© SQLI GROUP – 2014 chdessus@sqli.com Décembre 2014

LA MORALE DE L’HISTOIRE
+ LE PROJET SI N’EST QU’UNE COMPOSANTE D’UN PROJET MÉTIER, INDUSTRIEL, COMMERCIAL DE
DÉVELOPPEMENT DE L’ENTREPRISE.
Un sous-projet
+ L’ARRÊT OU L’ÉCHEC OU LE RETARD DU PROJET INFORMATIQUE EST SUSCEPTIBLE DE METTRE
EN PÉRIL LE PROJET MÉTIER.
Le projet métier est porteur de valeur pour l’entreprise. Le projet SI n’est qu’un moyen de la réaliser
+ L’ARRÊT, L’ÉCHEC OU LE RETARD DU PROJET INFORMATIQUE PEUT ÊTRE LA CAUSE D’UN ARRÊT
D’ACTIVITÉ TOTAL D’UNE ENTREPRISE.
34
POSITIONNEMENT DU PROJET INFORMATIQUE

ENJEUX DU PROJET
+ LES ENJEUX FORMALISENT LES RAISONS POUR LESQUELLES LE PROJET PRÉSENTE
UN INTÉRÊT POUR L’ORGANISATION (LES « POURQUOI » DU PROJET?)
+ UN PROJET DONT LES ENJEUX N’ONT PAS ÉTÉ IDENTIFIÉS
n’a ni d’importance ni de priorité dans la tête des décideurs.
Tout autre projet dont l’intérêt est bien clair dans l’esprit des décideurs lui sera préféré au
moment d’affecter des moyens ou d’arbitrer des priorités.
+ LES ENJEUX EXPRIMÉS PRÉJUGENT SOUVENT DE LA PRESSION ET DES CONFLITS QUI
DEVRONT ÊTRE GÉRÉS PAR LE CHEF DE PROJET ET NE DOIVENT PAS, À CE TITRE,
ÊTRE NÉGLIGÉS
35
POURQUOI

OBJECTIFS DU PROJET
+ OBJECTIFS « SMART »
ciblés
mesurables
réalistes : atteignables dans les délais
raisonnables : la technologie est en mesure de
les réaliser
+ SANS AMBIGUÏTÉ
les non-dits et les ambiguïtés finissent toujours
par empoisonner les relations sur un projet
+ COMMUNIQUER
S’assurer que les partenaires ont une perception
claire et convergente des objectifs
Expliciter la relation entre les objectifs et les
enjeux
Définir le résultat attendu
Expliquer en quoi les objectifs sont les plus
adaptés pour répondre aux enjeux
36
POUR QUOI ?
Spécifique
•Définir de façon précise ce que l’on doit réaliser, les objectifs à
atteindre
Mesurable
•Toute atteinte d’un objectif doit pouvoir être mesurer avec un
métrique, un indicateur
Atteignable
•Un objectif doit toujours être atteignable
Révisable
•Un objectif doit toujours être en rapport avec la situation rencontrée.
Il peut être révisé
Temps
•Un objectif doit pouvoir être réalisé et atteint dans une période de
temps raisonnable. Les délais doivent être déféinis

ATTEINDRE LES OBJECTIFS : UN EXERCICE PÉRILLEUX
+ LA QUADRATURE DU CERCLE !
+ SAVOIR PRIORISER, FAIRE DES HYPOTHÈSES, ANALYSER
LES RISQUES ET FAIRE DES CHOIX
» Si les coûts et délais sont fixes : on adapte le périmètre et la
qualité aux contraintes  on fait moins
» Si le périmètre est figé, on accepte d’éventuels dépassements de
charge ou délais ou on réduit les exigences de qualité.
» Si le délais est fixe, on planifiera différemment les réalisations
(lotissement, parallélisation, report de certaines activités)
+FAIRE DE L’AGILITÉ SON CREDO
37
DÉSÉQUILIBRE DES ENJEUX, PRIORITÉS ET OBJECTIFS
Périmètre Budget

PARTIES PRENANTES DU
PROJET
3.

ACTEURS DU PROJET
+ [IIBA] [BABOK 2]
Toute personne ou groupe de personnes impliquées dans la projet, la realisation d’une activité ou
impactés par celle ci.
+ [WIKIPEDIA]
Une partie prenante est un acteur, individuel ou collectif (groupe ou organisation), activement ou
passivement concerné par une décision ou un projet ; c'est-à-dire dont les intérêts peuvent être
affectés positivement ou négativement à la suite de son exécution (ou de sa non-exécution).
39
PARTIES-PRENANTES

ACTEURS DU PROJET
+ MAÎTRISE D’OUVRAGE
Celui qui demande. Celui qui définit le produit final, décrit les usages attendus du système
+ MAÎTRISE D’ŒUVRE
Celui qui construit, fournit un service
+ CONTRIBUTEURS
Celui qui contribue, soit à fabriquer, soit à définir.
+ CLIENT
Celui qui paye
+ UTILISATEUR
Celui qui va utiliser le produit final
40
CONCEPTS DE BASE

QUI EST MON CLIENT ?
41
QUI PAYE ?
Acheteurs et promeneurs :
Clients de la market place
Utilisateurs de la market
place
DSI Interne
SSII
Hébergeur
• Client : celui qui concrétise un achat par un paiement
• Utilisateur EXTERNE : celui qui utilise le site, browse, lit les
commentaires, sélectionne un article du catalogue, valide le
panier, créé un compte, change son profil…
• Utilisateur INTERNE : celui qui surveille la disponibilité du site,
celui qui met à jour le catalogue de produits, suit les
commandes, paiements, organise les livraisons…
Client
MOA
Fournisseur
MOE
Fournisseur des clients effectuant
les achats
Client
Utilisateur
Externe
Utilisateur
Interne
Décembre 2014

ACTEURS DU PROJET
42
PARTIES-PRENANTES (SOURCE : BABOK 2)
Partie-prenante Exemples, Rôle
Sponsor Manager, executive  affectation du budget
Business analyst Analyste fonctionnel, consultant, product owwner
Architecte technique, fonctionnel Concepteur
Utilisateur Défini par son organisation, description de fonction, rôle sur le projet
Equipes support Opération, help-desk, production
Chef de projet Responsable du projet, scrum master
Fournisseur Consultants externes, éditeurs
Testeur Vérification de la qualité des livrables
Organisme de régulation, contrôle
réglementaire
Définition des normes, règles à appliquer en coordination avec l’assurance qualité.
Contrôles externes
Assurance qualité Déclinaison des règles dans l’organisation. Contrôles internes

ACTEURS DU PROJET
+ CHEF DE PROJET
Responsable du chemin pour obtenir les résultats attendus
Développe la planification du projet
S’assure que le projet soit réalisé efficacement
+ MANAGER IT
Pilote de l’ensemble des services informatiques sous sa responsabilité
Maintient de la disponibilité, continuité, sécurité et capacité des systèmes  garantie, SLA, KPI
Efficacité et efficience des outils et de l’organisation SI.
Fournit aussi des ressources (principalement humaines) au projet  maîtrise d’oeuvre
+ SPONSOR
Celui à qui le chef de projet rapporte
Prend les décisions principales concernant le destin du projet
Le sponsor a généralement la responsabilité budgétaire
+ EQUIPE PROJET
Soutient le chef de projet
Travaille efficacement pour livrer un produit qui satisfait le client
Talents et compétences de chaque membre se complètent
43
EQUIPE PROJET

ACTEURS DU PROJET
+ CLIENT
Personne ou organisation pour qui le produit est développé
Fournit aussi des ressources (principalement humaines) au projet  maîtrise d’ouvrage
Approuve une partie des livrables
+ AUTRES PARTIES PRENANTES
PMO : Définition et diffusion du référentiel méthodologique, garant de l’application des bonnes pratiques
Le help desk
Le service achat
Le contrôle de gestion
+ SANS OUBLIER
L’architecte
Le chef de projet production
Les fournisseurs
Autres chefs de projet et contributeurs
44
EQUIPE PROJET

AMÉLIORER LES PRATIQUES
45
MODÈLES DE « BONNES PRATIQUES »
4.

+ LA PRATIQUE INFORMATIQUE EN ENTREPRISE DATE DES ANNÉES 1960.
En 2014, nous sommes toujours sur un modèle peu industrialisé, peu fiable, avec peu de
capitalisation
+ LE MODÈLE ÉCONOMIQUE RESTE BASÉ SUR LE CHANGEMENT PERMANENT ET
L’INSTABILITÉ DES TECHNOLOGIES PROPOSÉES
Les applications développées sont « jetables »
80% des technologies utilisées n’existeront plus dans 10 ans
Nous sommes encore en recherche d’usage  « internet of things »
+ CE N’EST PAS DE L’AGILITÉ MAIS DE L’INSTABILITÉ
+ FAISONS LE PARALLÈLE AVEC UN AÉROPORT
46
PROJETS DE SYSTÈMES D’INFORMATION

+ STATISTIQUE
Tout individu commet 2 erreurs par jour
Le projet détecte 80% des anomalies produites.
+ S’ENGAGER SUR UN TAUX DE DÉFAUT EN FIN DE PROJET, APRÈS LA RECETTE INTERNE
EFFECTUÉE PAR LE PROJET
Nb anomalies/jours de travail :
› Taux = 0,2
20 anomalies restantes pour 100 jours de projet.
› Détection en cours de projet 75 – 80% des anomalies
Pour 100 jours de projet, 5 anomalies résiduelles détectées à la livraison par le client
› Anomalies bloquantes =2%
Pour 100 jours de projet : aucune anomalie bloquante
1 anomalie bloquante pour 1000 jours de projet détectée par le client.
47
FIABILISER ET METTRE SOUS CONTRÔLE
+ EXEMPLE D’UN AÉROPORT :
9 000 000 passagers/an  environ 25 000 passagers/jour
150 000 mouvements d’avion/an  environ 410 mouvements/jour
Remplissage moyen d’un avion : 60 passagers
Décembre 2014

48
FIABILISER ET METTRE SOUS CONTRÔLE
+ TAUX DE DÉFAUT = 0,1 À 0,3 INCIDENTS GRAVES OU MAJEURS : 2%
+ IL A FALLU UNE RÉVOLUTION INDUSTRIELLE, QUELQUES RÉVOLUTIONS SOCIALES ET
PLUSIEURS ACCIDENTS MAJEURS POUR QUE L’INDUSTRIE SE « SÉCURISE »,
>220ANS
Décembre 2014

+CHAOS MANIFESTO DU STANDISH GROUP
http://www.standishgroup.com/about
+ANALYSE DES CAUSES DES ÉCHECS DES PROJETS
49
ETAT DES LIEUX DU STANDISH GROUP POUR LES PROJETS DE SI

+UN ÉCHEC C’EST
» Un abandon du projet, de l’enjeu sous-tendu, du budget déjà engagé
» Un résultat non conforme, un bénéfice amputé, des contraintes
opérationnelles douloureuses
» Un retard qui pénalise durablement le fonctionnement de l’entreprise,
provoquant une perte de crédibilité et de compétitivité
» Une inflation non maîtrisée du budget, un ROI long ou incertain
50
ECHOUER SELON LE STANDISH GROUP
Echec = non atteinte des objectifs et engagements initiaux
Qualité, Coût, Délais, Périmètre

+CONSTATS RÉCENTS : L’AUGMENTATION DU TAUX DE RÉUSSITE DES
PROJETS
+RAISONS ÉVOQUÉES :
» Généralisation des méthodes ou principes de gestion de
projets
» Meilleure gestion des risques
» Développement des Projet Management Office (PMO) qui
apporte une meilleure maturité dans la gestion des projets à
savoir la séparation des rôles de pilotage et des
responsabilités fonctionnelles ou techniques.
» Apport des méthodes agiles
51
STANDISH GROUP - RAISONS DES AMÉLIORATIONS CONSTATÉES

CADRER PROJET
52
PROPOSITION DE VALEUR
5.

CADRER LE PROJET
+ TOUT PROJET DOIT ÊTRE CADRÉ AU REGARD DE LA VALEUR APPORTÉE ET DES
ENJEUX
+ BÉNÉFICES
Identifier ce que doit apporter le projet : Utilité et Garantie
› Utilité « Fit for purpose »
Le service répond aux attentes, objectifs des clients (customers)
› Garantie « Fit for use »
Le service est disponible lorsque le client en a besoin.
+ COÛTS :
Evaluer le coût total de possession
53

CADRER LE PROJET
54
BÉNÉFICES : UTILITÉ ET GARANTIE – SOURCE : ITIL V3 2011
Performances
Contraintes supprimées
ou réduites
OU
Disponibilité
Capacité
Continuité
Sécurité
ET
ET
GARANTIE
UTILITE
Valeur créée
Bénéfices
Fonctionnalités
L’utilité augmente la performance.
La garantie atténue les variations de performance.
Décembre 2014

CADRER LE PROJET
+ COÛT TOTAL DE POSSESSION (CTO OU TCO)
» Concept industriel
» Coût global d'un bien ou d’un service, tout au long de son
cycle de vie jusqu’à son arrêt complet, sa déconstruction
ou son recyclage.
» Le maintien du produit ou service compte pour plus
de 50% du coût de possession.
» Le système de soutien doit être conçu en même temps
que l’on conçoit le produit ou le service
55
Achat Installation Implémentation
Maintenance Réparations Mises à jour
Services Support Sécurité
Formation
Arrêt du service
Mise au rebut
Recyclage
Déconstruction

CADRER LE PROJET
+LES SERVICES N’ONT PAS DE VALEUR INTRINSÈQUE
La valeur n’est pas le coût de fabrication du produit ou du
service
La valeur va dépendre des circonstances
La valeur est définie par le client
» Niveau de réponse du service aux attentes du client >>
satisfaction
» Prix ou budget que le client accepte de payer
» Perception influencée par ce que propose les concurrents
Le prix du service est défini par les « usages », la « valeur perçue »
56
VALEUR D’UN SERVICE
Service
rendu
Fonctionnalité - Utilité

CADRER LE PROJET
+ SUR LES PROJETS COMPLEXES, NE PAS HÉSITER À FORMALISER LA PROPOSITION DE
VALEUR
57
DOSSIER DE CADRAGE

DÉMARCHE DE PILOTAGE ET
CONDUITE DE PROJET
58
MÉTHODE(S)
6.

PILOTAGE & CONDUITE DE PROJETS
Conduire un projet ≠ Piloter un projet
Activités opérationnelles :
 Construire ou mettre à jour un planning, un plan de
charge
 Mettre à jour un référentiel, effectuer une revue documentaire
 Analyser et évaluer les risques
 Rédiger un compte-rendu
 Préparer un comité
 Analyser un indicateur, construire le TdB
…
Activités de pilotage :
 Prise de décision stratégique : arrêt,
changement majeur de périmètre
 Porter l’engagement d’atteinte des
objectifs du projet
 Gouvernance  priorisation, budget
 Alerte, escalade au sponsor
 Participer à un comité
Directeur de projet
Responsable hiérarchique
Chef de projet
Escalade

+ ADOPTER LE PDCA COMME PRINCIPE DE STRUCTURATION DE VOS ACTIVITÉS :
» Tout projet doit être conduit dans le cadre d’une démarche d’amélioration progressive et
réaliste.
» Pas de projet pharaonique dont on ne maîtrise ni le périmètre, ni les coûts ni les gains, ni les
enjeux.
» Travailler par étapes successives.
» Privilégier des démarches itératives, y compris dans la structuration des projets et leur
imbrication.
+ SE DONNER LA VISION GLOBALE PUIS PRIVILÉGIER LES « QUICK-WIN » : ON GAGNE
EN DÉPENSANT PEU.
+ TOUJOURS S’APPUYER SUR UNE DÉMARCHE STRUCTURÉE.
60
AMÉLIORATION CONTINUE COMME PRINCIPE DE RÉALISATION DES CHANGEMENTS

+ DÉMARCHE MÉTHODOLOGIQUE :
› Forme de prévention prospective qui doit
aboutir au zéro défaut avec efficacité et en
organisant les équipes.
› Structurer et assurer le bon déroulement du
projet
• Atteindre les objectifs du projet
• Respecter les délais, coûts, qualité
attendus
• Coordonner les ressources
› Tout en maîtrisant risques et aléas
61
DÉFINITION
« Il n'y a que deux espèces de plans de
campagne, les bons et les mauvais.
Les bons échouent presque toujours
par des circonstances imprévues qui
font souvent réussir les mauvais. »
Napoléon Bonaparte

+ DÉMARCHE
Décrire le cycle de vie du projet
+ MÉTHODOLOGIE
Définir des modèles de documents, processus, procédures et modes de travail
Instructions, façons de faire propres à l’entreprise, type de projet, circonstances.
+ UNE MOYENNE DE 7 À 8 ÉTAPES, POUR RÉUSSIR SON PROJET
Atteindre les objectifs du projet
Répondre aux exigences et besoins des utilisateurs et clients
Quelque soit la méthode choisie : PRINCE2, PMBOK…
62
MÉTHODOLOGIE

+ PRINCE 2
63
STANDARDS
+ PMBOK
Faux-ami
Planning ≠ Scheduling
Cycle de vie ≠ Calendrier
(Phases, Livrables) (Gantt, Pert)

64
EXEMPLES – EXPÉRIENCE DE MISE EN ŒUVRE DE DÉMARCHES
En formation, nous vous présenterons les
démarches développées lors de nos missions de
conseil.
Nous en analyserons les avantages et
inconvénients.

+ 8 ÉTAPES
65
MÉTHODE GÉNÉRIQUE
Définir
Cadrer et
Sécuriser
Surveiller
Conduire &
piloter
Objectifs
Besoins
Exigences
Décider
Lancer
Préparer
Réaliser
Documenter
Effectuer la
transition
Contrôler
l’atteinte des
objectifs
Fermer le projet

+ UN PROJET EST TOUJOURS PORTEUR DE CHANGEMENT
+ SE LAISSER DE LA SOUPLESSE :
Toute méthodologie est itérative
» Sur l’ensemble des phases de la méthode
» Entre les phases
» Au sein de chaque phase
+ NE JAMAIS RÉALISER DE CHANGEMENT RADICAL
Des objectifs progressifs et atteignables
Amélioration continue
Agir au moindre risque et au moindre coût.
66
APPLIQUER LA MÉTHODE DES « PETITS PAS » (kaizen)
Itération 1 Itération 2 Itération 3

67
DÉFINIR – CADRER – SÉCURISER
DÉCIDER
Objectifs
Evaluer la faisabilité et l’intérêt du chantier
Prérequis Avoir un besoin et un sponsor
Activités
Identifier et formaliser le besoin
Estimer une charge
Estimer un cout
Etudier des pistes de solutions
Livrables
Business Case :
• Dossier de cadrage
• Référentiel exigences
• Chiffrage et planning macro
• Concept validé et confirmé
• Solution identifiée
• Budget défini et gains identifiés
Critères Fin
de phase
Atteinte des jalons :
GO/NO GO du sponsor pour démarrer le projet
Décider

PHASE «LANCER»
68Décembre 2014
Objectifs
Décrire le périmètre du projet
Organiser et cadrer le projet
Prérequis Projet décidé
Activités
Reformaliser et structurer l’expression du besoin
Identifier les parties-prenantes, organiser et cadrer le projet
Evaluer la charge/délais/coût
Evaluer les risques
Réunion de lancement*
Livrables
• Expression du besoin structurée
• Document de cadrage
• Phases, activités et Planning (WBS)
• Charges et budget revus
• Evaluation des risques
Critères Fin de
phase
Atteinte des jalons :
GO/NO GO du sponsor pour poursuivre le projet

PHASE «PRÉPARER»
Objectifs
Instancier les modes de suivis (rituels, indicateurs) et l’outillage
Planifier les rituels
Prérequis GO/NO GO du sponsor en fin de phase précédente « Lancer »
Activités
Instancier les outils de pilotage du projet
Evaluer les risques
Initialiser les rituels de suivi*
Si besoin, poursuivre la structuration de l’expression du besoin
Livrables
• Outillage instancié : suivi des actions, suivi des changements, suivi des livrables, suivi des jalons,
planning, risques
• Périmètre validé
• Phases et planning validés
• Responsabilités opérationnelles déterminées
• Rituels de pilotage organisés *
Critères
Fin de phase
CR réunion de lancement avec les parties-prenantes validé *
Rituels de suivi instanciés. Indicateurs projet initialisés et suivis.*
Planning instancié
Risques opérationnels évalués
Périmètre du projet revu et validé

PHASE «RÉALISER»
Objectifs
Concevoir, fabriquer et qualifier la solution répondant au PBS
Réaliser les activités décrites dans le WBS et selon le planning et charge définis.
Prérequis
Projet lancé
Périmètre d’activités et responsabilités définies
Activités
Concevoir techniquement (et fonctionnellement le cas échéant)
Fabriquer : installer, paramétrer, intégrer, tester
Industrialiser : rédiger les documentations techniques, rejouer les installations,
automatiser les livraisons …
Préparer la transition : conduite du changement (clients), gestes techniques à réaliser
Livrables
• Documentaires : spécifications, plan de transition, migration, plan de test, plan de
gestion de configuration, documentation d’installation, documentation de support,
exploitation …
• Techniques : paramétrage, développement si besoin, plateformes installées et
disponibles, produits installés et opérationnels, intégration avec les autres composants
effectuée…
• Suivi du projet effectué : rituels, risques, indicateurs
Critères
Fin de phase
Livrables définis dans le WBS sont remis et validés

PHASE «DOCUMENTER»
Objectifs
Rédiger et mettre à jour les livrables de conception et réalisation
Documenter les livrables pour la MEP (mise en production) et le
support
Prérequis
TOUT AU LONG DU PROJET
Dès la validation du concept et le lancement du projet.
Activités
Rédaction et mise à jour documentaire
Revue des livrables
Livrables
Livrables documentaires mis à jour ou rédigés
Critères de fin
de phase
Livrable revu et accepté par le destinataire
Attention,
DOCUMENTER est
réalisée tout au long du
projet.
N’est pas une phase au
sens séquentiel mais un
principe.

PHASE «DOCUMENTER»
+A RÉALISER TOUT AU LONG DU PROJET
+UNE ATTENTION PARTICULIÈRE SUR LA FIN DU PROJET :
En fin de réalisation et pendant la transition, on met à jour les livrables documentaires
*** pour les transmettre à l’équipe de support.
On organise une revue de livrables avec les équipes support, éventuellement une formation
*** y compris les livrables de conception
+LA DOCUMENTATION FACILITE LA SORTIE DU PROJET ET LE TRANSFERT
VERS LES ÉQUIPES SUPPORT POUR LE MAINTIEN EN CONDITIONS
OPÉRATIONNELLES.
En découle, son positionnement entre REALISER et EFFECTUER LA TRANSITION

PHASE «EFFECTUER LA TRANSITION»
Objectifs
Assurer la MEP sans régression  préparer le changement pour éviter les
régressions ou incidents
Passer en MCO
Assurer la conduite du changement, communication et formation auprès des clients,
utilisateurs internes ou externes
Prérequis
Solution recettée et intégrée
GO de déploiement ou expérimentation
Plan de déploiement
Activités
Rédiger le plan de passage en MCO, organiser la réversibilité projet  support
Préparer les changements (CAB) et MEP. Planifier les opérations.
Assurer le support pour la MEP et lancement du MCO
Organiser la conduite du changement, communication, formation
Livrables
Réversibilité en MCO
Changements (CAB) préparés et maîtrisés
Conduite du changement organisée
Critères de
fin de phase
Réversibilité vers les équipes de support effectuée
MEP effectuée
Conduite du changement organisée, voir réalisée.

PHASE «CONTRÔLER L’ATTEINTE DES OBJECTIFS »
Objectifs
S’assurer que le projet a fourni la « valeur » attendue
Prérequis
Le projet est déployé ou en cours de déploiement avec une phase d’expérimentation
effectuée et « probante »
Activités
S’assurer que les gains attendus sont réalisés ou en cours de réalisation. Exemple :
• Nouvelle organisation déployée
• Nouveaux marchés
• Gains financiers
• Etc…
Contrôler le respect des engagements de départs : coûts, qualité, délais.
Livrables
Document de revue des objectifs définis en phase de lancement dans le document de
cadrage
Critères de fin
de phase
Objectifs atteints ou partiellement atteints
Plan d’actions

PHASE «FERMER»
Objectifs
Clore le projet
Archiver la documentation
Libérer les équipes
Prérequis Solution livrée, validée
Activités
Réaliser le bilan du projet
Planifier les actions post-projet
Clore le suivi budgétaire
Livrables
Bilan du projet
Plan d’actions d’amélioration
Plan de maintenance
Critères Fin de
phase
Bilan rédigé et transmis

PHASE «SURVEILLER CONDUIRE & PILOTER»
Objectifs
Effectuer le suivi du projet
Coordonner les interventions des parties-prenantes
S’assurer de la production des livrables : forme, fond, qualité, délais, charges
Prérequis
Le projet est lancé.
Cette activité démarre dès la phase de « préparation »
Activités
Animer les comités de projet, comités de pilotage. Préparer les supports, rédiger les CR
Suivre l’avancement opérationnel : production des livrables, réalisation des actions
Effectuer les évaluations de risques (à minima 1/mois)
Suivre les indicateurs : jalons, charges, délais, budget (s’il y a lieu)
Livrables
Fiche de synthèse du projet mise à jour
Météo du projet
Comités de projet : documents de préparation, CR et tenue des réunions
Critères de fin
de phase
Le projet est terminé
À la fin de la phase « Fermer »

SUPPORT AU PROJET «CONTRÔLER LA QUALITÉ»
+TOUTE MÉTHODE EST ASSOCIÉE À DES MOYENS DE CONTRÔLE AYANT POUR
OBJECTIFS :
Coordonner le déploiement
Contrôler l’appropriation des processus et procédures établis
Contrôler l’usage
Proposer de la formation
Etablir un plan d’amélioration de la méthode
+LE CONTRÔLE PRÉCÈDE LA MÉTHODE.
+LE CONTRÔLE EST AUSSI ET SURTOUT UN OUTIL DE
DÉPLOIEMENT.

FOCUS SUR LES DÉMARCHES
AGILES & ITÉRATIVES
78
MÉTHODE(S)
7.

MÉTHODE(S) AGILE(S)
79
VALEURS DU MANIFESTE AGILE
+ LES DÉMARCHES AGILES :
Les individus et les interactions plutôt que les processus et les outils
Un produit qui fonctionne plutôt qu’une documentation exhaustive
La collaboration avec le client plutôt que la contractualisation des relations
L’acceptation du changement plutôt que la conformité aux plans

+ LES DÉMARCHES AGILES :
» manquent de rigueur et de discipline
» abolissent la conception
» n'offrent pas de vision à long terme du déroulement du projet
» engendrent une reprise perpétuelle du travail fini
» ne permettent pas de s'engager sur un contour fonctionnel fixe
» ne sont pas appropriées pour les produits critiques
» échouent comme les autres
» sont inappropriées pour le développement géographiquement distribués
» sont inappropriées aux grosses équipes
» nécessitent des développeurs compétents et motivés
» risquent d'élaborer des architectures non-évolutives
» vivent sur l'utopie du consensus dans l'équipe
80
IDÉES REÇUES À COMBATTRE

81
DÉFINITION
« Gestion de projet : Vers les méthodes agiles », V.Rota, 2007
« Une méthode agile est une approche itérative et incrémentale, qui est
menée dans un esprit collaboratif avec juste ce qu’il faut de formalisme.
Elle génère un produit de haute qualité tout en prenant en compte l’évolution
des besoins des clients »
Plusieurs méthodes
... de très nombreuses
techniques

SATISFAIRE LE CLIENT EST LA PRIORITÉ
ACCUEILLIR LES DEMANDES DE CHANGEMENT « À
BRAS OUVERTS »
LIVRER LE PLUS SOUVENT POSSIBLE DES
VERSIONS OPÉRATIONNELLES DE L’APPLICATION
CONSTRUIRE DES PROJETS AUTOUR D’INDIVIDUS
MOTIVÉS
PRIVILÉGIER LA CONVERSATION EN FACE À FACE
MESURER L’AVANCEMENT DU PROJET EN TERMES
DE FONCTIONNALITÉS DE L’APPLICATION
82
MANIFESTE AGILE
FAIRE AVANCER LE PROJET À UN RYTHME
SOUTENABLE ET CONSTANT
PORTER UNE ATTENTION CONTINUE À L’EXCELLENCE
TECHNIQUE ET À LA CONCEPTION
FAVORISER LA SIMPLICITÉ
RESPONSABILISER LES ÉQUIPES (AUTO-ORGANISER)
AJUSTER, À INTERVALLES RÉGULIERS, SES
PRATIQUES ET PROCESSUS POUR ÊTRE PLUS
EFFICACE

83
VUE D’ENSEMBLE
Lean
Agile
Scrum
XP
Optimisation globale
Respect de individus
Réduction des gaspillages
Capitalisation
Limiter le travail à la capacité
Programmation en binôme
Automatisation des tests
Intégration continue, TDDSource : Henrik Kniberg

84
COMMENT METTRE EN ŒUVRE L’AGILITÉ
+ 0 À n ITÉRATIONS
+ PLANIFICATION DES SPRINTS
+ AU COURS DE CHAQUE SPRINT
Réunion quotidienne
Mise en visibilité des informations du projet
Courbe du reste à faire (RAF)
+ DÉMONSTRATIONS DU « PRODUIT », MISE EN VISIBILITÉ DE L’AVANCEMENT
+ RÉTROSPECTIVE EN FIN DE SPRINT
Boucle d’amélioration et planification du contenu du sprint suivant
Anomalies à corriger, améliorations de fonctionnalités, nouvelles fonctionnalités

NOTRE MÉTHODOLOGIE « SKILLS »
85
PILOTAGE PAR LES ENJEUX MÉTIERS STRATÉGIQUES
Anticipation
des problèmes
Livrer rapidement
une1ère version
+Gestion de projet
rigoureuse
Encourager la gestion
des changements
ATTEINTE DES ENJEUX STRATÉGIQUES CLIENT
Adéquation au besoin Pilotage par les risques Qualité des livrables Garantie des délais
CMMI AGILITÉ
50 profils certifiés
ScrumMasters
Seule SSII détenant une
certification niveau 5 (fr)
SQLI garde le meilleur
des 2 mondes
en fonction du contexte

CYCLE DE VIE AGILE
1.2 - 09/04/2013
N itérations
Déploiement
Analyse du produit
Référentiel d’exigence priorisé
Exigences techniques et
fonctionnelles de l’itération 1
Analyse graphique et
ergonomique
Concepts clés
Maquette
Analyse technique
Architecture technique
Architecture applicative
Organisation du projet
Plan Qualité Projet
Stratégie de test
Conception de l’itération
Conception métier et ergonomique
Conception technique
Scénarios de recette
Construction
Développements et tests
Réception
Démonstration du produit
Réception par vos équipes
Préparation itération n+1
Gestion du changement
Contenu de l’itération n+1
Installation en production
Documentation d’installation
Migration des données (si vendu)
Validation du bon fonctionnement
Mise en production
Accompagnement au déploiement
Formation des utilisateurs (si vendu)
Formation des exploitants (si vendu)
Lancement release 2
Définition

PLANIFIER LES ITÉRATIONS
RÉALISATION DU PLANNING
1.2 - 09/04/2013
Définition
Itération 1
Itération 2
Itération 3
Itération 4
Déploiement
Itération 5
Itération 6
Itération 7
Dépl.
Sept 201x Oct 201x Nov 201x Dec 201x Mai 201y Juin 201yJanv 201y Fév 201y Mars 201y Avril 201y
V1 en production : 17/03/201y
22/02/201y : Fin recette
V2 en production : 15/06/201y
30/05/201y :
Fin recette V2
• V1 : 4 itérations de 4 semaines + 4 semaines de déploiement
• V2 : 3 itérations de 4 semaines + 2 semaines de déploiement

+ UN DIRECTEUR DE PRODUIT / PRODUCT OWNER
A la responsabilité de la définition des
exigences:
› est propriétaire du backlog de produit
(liste des fonctionnalités à développer):
contenu et priorités
Disponible durant le sprint, et en particulier
› lors de la réunion de planification de
sprint
› lors de la revue de sprint
+ L’ÉQUIPE
Elle est constituée des personnes
nécessaires pour produire le livrable
› Concepteur, développeur, expert
technique ..
› Expertise ponctuelle : ergonome,
architecte
88
RÔLES ET RESPONSABILITÉS
+ LE SCRUM MASTER  COORDINATION ET
CONDUITE, FACILITATEUR
Veille à une bonne interaction entre l’équipe et
le directeur de produit
Facilite la réalisation du projet (résolution des
problèmes, interface ..)
Support à l’équipe pour améliorer sa
productivité (pratique d’ingénierie, outils..)
Facilite la montée en puissance de l’équipe :
compétence et autonomie
Met à jour l’information d’avancement et la
rend visible de tous
Informe le management de l’avancement du
projet, alerte

89
RÔLES ET RESPONSABILITÉS « PRODUCT OWNER »
Décrit le QUOI, jamais le COMMENT
Définit la valeur métier
Garant de la vision PRODUIT
Priorise la BACKLOG
Prépare l’itération suivante
Ecrit les histoires (user stories)
Présente les histoires en début d’itération
(cas d’usage et contextes)
Participe aux démonstrations
Effectue les recettes des produits

90
RÔLES ET RESPONSABILITÉS « SCRUM MASTER »
Chef de
projet
Architecte
Responsable
technique
SCRUM = MÊLÉE
blog.xebia.fr/2013/07/24/dessine-moi-un-scrum-
master

+ POINTS FORTS
Concentration sur le besoin du client
Maîtrise des risques
Favorise la cohésion de l’équipe
Innovant : programmation en duo, stand-up …
Permet une intervention constante des utilisateurs
91
+ POINTS FAIBLES
Vision macroscopique au-delà du « sprint »
Nécessite une intervention forte et constante des
utilisateurs, ainsi qu’une vision claire des objectifs
Difficulté à implémenter pour équipe > 10 personnes
Vigilance sur la qualité : potentiel de « quick &
dirty » élevé
REX : Ça marche.
Y compris dans un contexte de FORFAIT avec un budget et délais fixes
- Se donner la « big picture » du produit final, définir les USER STORIES en amont
- Définir les objectifs métier à atteindre et les critères de réussite
- Le chemin vers la cible est adapté au contexte, de SPRINT en SPRINT

+ POINTS FORTS
Concentration sur le besoin du client
Maîtrise des risques
Favorise la cohésion de l’équipe
Innovant : programmation en duo, stand-up …
Permet une intervention constante des utilisateurs
92
+ POINTS FAIBLES
Vision macroscopique au-delà du « sprint »
Nécessite une intervention forte et constante des
utilisateurs, ainsi qu’une vision claire des objectifs
Difficulté à implémenter pour équipe > 10 personnes
Vigilance sur la qualité : potentiel de « quick &
dirty » élevé
REX
Conditions de réussite :
- Un PRODUCT OWNER très impliqué et ayant la capacité d’adapter la cible fonctionnelle.
- Documenter au fur et à mesure >> déploiement et maintenance
Privilégier un cycle de vie en cascade si
• Le projet est très court
• La MOA ne peut pas s'impliquer fortement dans le projet

93
CRITÈRES D’ÉLIGIBILITÉ
+ EXIGENCES
Objectifs clairs
Stabilité de la vision d’ensemble du produit final
Criticité
+ VOLUMÉTRIE DU PROJET
Charge, taille de l’équipe
+ AXES DE PILOTAGE
Délai / budget
Périmètre
+ CONTEXTE FONCTIONNEL ET TECHNIQUE :
Conception modulaire et niveau de contrainte
d'intégration
Automatisation des tests
Intégration continue des développements
Automatisation du déploiement
Difficulté technique
Dépendance / interface avec d'autres projets /
applications

GOUVERNER LE PROJET
8.

GOUVERNER LE PROJET
+ PMO
Project management office
+ P3MO
Project Program Portfolio management office
+ PMO, CONCEPT ANGLO-SAXON
En français, Bureau de gestion des projets
+ COORDONNER LA GESTION DES PROJETS
Le PMO est chargé de la documentation, du tutorat et de l'évaluation de la gestion des projets,
ainsi que du suivi de la mise en œuvre de la démarche définie.
95
COORDONNER ET SUIVRE
Assurance
Qualité
Contrôle de
gestion
Suivi des
engagements
Pilotage des
contrats
Vérifier atteinte
des objectifs et
des gains Suivi des
investissements
et coûts
Maîtriser les
risques

GOUVERNER LE PROJET
+ 3 MÉTIERS POUR LES SYSTÈMES
D’INFORMATION
» Directeur de projet
» Chef de projet MOA
» Chef de projet MOE
+ UN RÔLE : PMO
» Poste de contrôle et suivi à la frontière de
la gestion de projet, planification,
assurance qualité et amélioration des
processus.
» Contrôle de gestion
96
MÉTIERS
Source : http://www.cigref.fr

GOUVERNER LE PROJET
+ COMITÉ DE PILOTAGE :
Prendre les décisions avec les décideurs concernés
› Budget
› Délai
› Moyens (matériels et humains)
Le comité de pilotage n'a pas pour but de régler les problèmes opérationnels, mais de
prendre les décisions importantes qui permettront de les régler le cas échéant
+ COMITÉ DE PROJET :
Préparer les décisions avec les acteurs concernés
Effectuer le suivi opérationnel avec les acteurs concernés
› Avancement de la semaine
› Problèmes en cours (techniques / fonctionnels / organisationnels) et axes de
résolution
› Actions à mener
Maintenir des points de communication entre les interlocuteurs opérationnels du projet
97
2 NIVEAUX DE GOUVERNANCE
Vision stratégique, atteinte des objectifs et enjeux du projet
Vision opérationnelle, avancement des phases et étapes du projet

COMPRENDRE LES BESOINS
98
EXIGENCES - PBS
9.

DÉFINITION D’UNE EXIGENCE
+ UN BESOIN
une ou plusieurs exigences
A considérer au sens le plus large possible, comme une capacité ou une condition attendue par
une partie prenante pour résoudre un problème ou réaliser un objectif
Documentée
+ UNE EXIGENCE CONDUIT À DÉCRIRE LES RÔLES, PROCESSUS, RÈGLES, SOLUTIONS
ET DES SYSTÈMES D’INFORMATION D’UNE ENTREPRISE.
+ UNE GRANULARITÉ TRÈS FINE OU AU CONTRAIRE TRÈS MACRO
+ PLUSIEURS NIVEAUX D’EXIGENCES
99
SOURCE : WWW.IIBA.ORG BABOK : BUSINESS ANALYSIS BOOK OF KNOWLEDGE

100
Classification Description Outil d’analyse du BABOK
Business requirements
Exigences métier
Niveau le plus haut, décrit le POURQUOI Architecture d’entreprise
Processus
Stakeholder requirements
Exigences des parties
prenantes
Liens entre Business requirements et Solution
requirements
Traduction des exigences métier
Analyse des exigences
Solution requirements
Exigences de la solution
Décrire les caractéristiques d’une solution ou d’un
composant qui réponde à un « Business
requirement » ou un « Stakeholder requirement ».
Fonctionnel ou non fonctionnel.
Analyse des solutions et leur
validation
Transition requirements
Exigences de déploiement
et de transition
Faciliter la transition de l’entreprise entre un état
initial vers l’état futur attendu. Exemple : conduite
du changement, reprise de données, formations…

101
+ UN RÉFÉRENTIEL DÉDIÉ AUX EXIGENCES ET À LA « BUSINESS ANALYSIS »

EXPRESSION DES BESOINS
+ UNE EXIGENCE EST UN BESOIN PAR RAPPORT À UN PRODUIT, OUTIL, OBJET OU UN
SERVICE
Une capacité, une condition
Un service à rendre, objet, outil, produit à concevoir et/ou fabriquer
Une contrainte à respecter
Une contrainte à enlever
+ UTILISER LES NOTIONS D’utilité ET DE garantie
Fonctionnalités, usage, caractéristiques du produit, service
Niveaux de service et qualité attendus
102
GÉNÉRALISATION

103
GÉNÉRALISATION
+ UTILITE DE LA
SOLUTION
+ GARANTIE
DU SERVICE

+ LE DEMANDEUR EST ASSEZ LIBRE DE
DÉCRIRE
› SITUATION ACTUELLE
› SITUATION FUTURE SOUHAITÉE
› CONTRAINTES, DÉPENDANCES CRITIQUES
› BUDGET, DÉLAIS
104
DIALOGUE
+ CELUI QUI REÇOIT LA DEMANDE
› S’ASSURE DE L’EXHAUSTIVITÉ DES BESOINS
› STRUCTURE LES BESOINS
› S’ASSURE DE SON ÉVALUATION ET
VALIDATION

+ UN BESOIN DOIT ÊTRE ÉVALUÉ
Il a un coût pour l’entreprise
Il doit être pertinent au regard de l’usage d’une solution, la stratégie d’évolution d’un outil, technologie,
infrastructure
Les demandes conséquentes, structurantes, importantes doivent en plus décrire un enjeu; ces
demandes doivent donc être portées par un sponsor, membre d’une direction.
+ UN BESOIN DOIT ÊTRE JUSTIFIÉ AU REGARD DE SA VALEUR POUR LE BUSINESS
Atteinte ou satisfaction d’un objectif de l’entreprise
Enjeux
+ UN BESOIN DOIT ÊTRE VALIDÉ
Décision
Budget, planning
Libération de ressources
Plan stratégique
105
EVALUATION, JUSTIFICATION ET VALIDATION
Validation

+« SATISFACTION ET INSATISFACTION NE SONT
PAS SYMÉTRIQUES »
» La droite « bleue » du schéma est essentiellement
théorique.
+UN DEMANDEUR DONNE RAREMENT UNE
VISION EXHAUSTIVE, JUSTE ET PRÉCISE DE
SON BESOIN
» Incompréhension humaine, niveau de langage
différent
» Méconnaissance de l’incompréhension de l’autre
» Contexte : celui qui imagine la vision future n’est pas
celui qui la construit ni celui utilise
» Inconfort avec le langage oral ou écrit
106
MODÈLE DE KANO
http://fr.wikipedia.org/wiki/Modèle_de_Kano

+DÉCRIRE LES BESOINS FONCTIONNELS
Un besoin, une exigence qui lorsqu’il est satisfait permet à un utilisateur de réaliser une fonction
ou lui enlève une contrainte.  UTILITE
+DÉCRIRE LES BESOINS NON FONCTIONNELS
Généralement des contraintes qui pèsent sur le système. Exemple : 24/7  GARANTIE
+++ NE PAS OUBLIER LES CONTRAINTES
D’implémentation : plateforme, ressources, intégration, déploiement, conformité aux standards,
contraintes physiques d’implémentation
D’interface :
› ERGONOMIE, FACILITÉ D’USAGE
› INTEROPÉRABILITÉ AVEC LES AUTRES SYSTÈMES, FLUX
107
CAS DU SYSTÈME D’INFORMATION

+FUNCTIONNABILITY
Généralités, capacité, fonction souhaitée y compris la
sécurité
Connectivité, licences
+USABILITY
Accessibilité, facteurs humains, look & feel
Documentation
+RELIABILITY
Résistance aux pannes, défaillances, temps moyen
entre 2 défaillances
Capacité de restauration, continuité de service, suivi et
surveillance
108
CAS DU SYSTÈME D’INFORMATION – MODÈLE FURPS++
+PERFORMANCE
Vitesse d’exécution, temps de réponse
Consommation de ressources
+SUPPORTABILITY
Testabilité, Capacité d’évolution (extensibilité,
montée en charge)
Compatibilité, portabilité
Maintenabilité, instabilité
Possibilité de configuration, adaptabilité aux
besoins

+LES EXIGENCES DÉFINISSENT LE PÉRIMÈTRE DU PROJET
Intégrer tous les usages, y compris ceux des équipes support
+LES EXIGENCES ÉVOLUENT AU COURS DU PROJET
Traçabilité totale et systématique de tous les changements
Faire une analyse d’impact et rechiffrer
+GRANULARITÉ
Une fonction simple, testable unitairement, dont on entrevoit la solution
On rédige le cas de test de l’exigence en même temps que l’exigence
109
CAS DU SYSTÈME D’INFORMATION

110
MÉTHODE DE DÉCOUVERTE DES EXIGENCES
+ FAIRE VALIDER LE RÉFÉRENTIEL AU DÉMARRAGE
+ RÉDIGER LES CRITÈRES DE CHOIX DE LA SOLUTION
+ RÉDIGER LE PLAN DE TESTS ET LE CAHIER DE RECETTE
+ EFFECTUER DES REVUES D’EXIGENCES AVEC LES
PARTIES-PRENANTES TOUT AU LONG DU PROJET
+ SUIVRE L’AVANCEMENT DU PROJET : TAUX DE
COUVERTURE
Mettre en place un suivi régulier du périmètre

+LE RÉFÉRENTIEL DES EXIGENCES PERMET :
De grouper les exigences par thème et
d’identifier les fonctions à mettre en œuvre
+PRODUCT BREAKDOWN STRUCTURE
Regroupement d’exigences en fonctionnalités de la solution
» Le PBS est toujours obtenu après avoir rédigé le référentiel des
exigences.
» Toujours repartir du besoin, pas de la solution imaginée.
» Ne jamais rédiger un PBS sans avoir fait une analyse du besoin sous
forme d’exigences
111
FONCTIONS ATTENDUES DE LA SOLUTION
Le référentiel des
exigences permet
de cartographier
les fonctions
attendues

112
FONCTIONS ATTENDUES DE LA SOLUTION
Expression du besoin
Identifier les Fonctions
attendues
Concevoir
techniquement la
solution
Construire la solution
Maintenir la solution
QUOI, POURQUOI,
QUAND, COMBIEN,
POUR QUI, QUELLE
PERFORMANCE
QUOI, POURQUOI
COMMENT
Fonctions de
Service (FS)
Fonctions
Techniques
(FT)
Attentes des parties-prenantes : commanditaire, utilisateur direct ou
indirect
Pas forcément immédiatement structuré et complet
Celui qui conçoit doit structurer le besoin et le faire valider au
demandeur pour le compléter
Reformulation structurée de l’expression du besoin  spécifications
fonctionnelles ou techniques
Choisir la solution
Traduction de la FS en composant technique
Description de la solution mise en œuvre : composants techniques et
documentaires
Description des configurations : liens entre les composants techniques
et documentaires
Fabriquer, vérifier, intégrer, déployer
Surveiller, exploiter, gérer en configuration
Corriger
Faire évoluer
Référentiel
Exigences

113
MAÎTRISER LES CONFIGURATIONS
+ DÉCRIRE
à quoi ressemble le produit
ce qu’il est supposé faire
comment il doit être assemblé
comment il est supposé être utilisé
comment il est maintenu
+ PLUSIEURS NIVEAUX DE
DÉCOMPOSITION
+ PLUSIEURS VERSIONS DE
DÉCOMPOSITION
Configuration
telle que
conçue
Configuration telle
que construite
Configuration telle
que déployée et
maintenue
FT maintenues
Consignes exploitation et
maintenance
Manuel d’utilisation
FT implémentées
Procédure d’installation et
intégration
Doc de paramétrage
FS et FT conçues
Spécifications
DAT

+ CHAQUE BLOC EST SPÉCIFIÉ
On ne spécifie que ce qui est utile. On ne paraphrase pas ce qui est déjà écrit dans le référentiel
des exigences, on le complète.
+ POUR CHAQUE BLOC DU PBS
Nom, description
Exigences
Usage
Contraintes techniques, maintenance (support, exploitation)
Liens avec les autres éléments techniques
+ LES SPÉCIFICATIONS SONT GÉNÉRALEMENT RÉDIGÉES PAR LA MAÎTRISE D’ŒUVRE
ET VALIDÉES PAR LA MAÎTRISE D’OUVRAGE.
Les spécifications engagent la maîtrise d’œuvre.
114
SPÉCIFICATIONS DE LA SOLUTION
Performance attendue
Modalités de mise en œuvre
Données requises pour réaliser la fonction
Règles de gestion
Liens avec les autres éléments

STRUCTURER LES ACTIVITÉS
ET LIVRABLES
10.

STRUCTURER LES ACTIVITÉS ET LIVRABLES
+ LES PHASES, ÉTAPES SONT REPRÉSENTÉES SOUS FORME D’UN ARBRE :
› WORK BREAKDOWN STRUCTURE OU WBS
Organigramme des tâches
+ COMMENT FAIRE LE WBS ?
S’appuyer sur les phases du projets
Décliner les livrables à produire et activités à mener
+ A QUOI CELA SERT ?
Planifier les activités, attribuer des responsabilités
Réaliser un GANTT ou un PERT
116
WBS

117
PBS & WBS
+POUR DÉPLOYER UNE INFRASTRUCTURE | COMPOSANT TECHNIQUE |
SERVICE :
› Effectuer la décomposition technique à mettre en œuvre, jusqu’au niveau le plus fin
› Décrire les étapes de travail permettant de construire la solutions, les fonctions
techniques
+LE PBS : DÉCOMPOSITION TECHNIQUE
Support à la spécification des composants
Document en entrée de la gestion de configuration de vos
architectures/infrastructures déployées.
+LE WBS : ÉTAPES DE TRAVAIL
utilisé pour planifier les activités et suivre leur avancement.

118
PBS & WBS
PBS (QUOI FAIRE)
• Décrire les produits techniques
et documentaires à fabriquer
• Décrire les liens entre les sous-
produits
• En lien avec le référentiel des
exigences
Décomposition technique
WBS (COMMENT FAIRE)
• Décrire les étapes de fabrication
• Décrire les livrables
• Décrire les responsabilités
• Planifier et suivre l’avancement
des livrables
Planning & jalons

EVALUER LA CHARGE DE TRAVAIL
119
(EFFORT)
11.

EVALUER LA CHARGE
+ EVALUER L’EFFORT REQUIS POUR RÉALISER UNE ACTIVITÉ
+ AVEC UN ENJEU FORT
En fin de projet, la charge réelle devra être proche (ou égale à) l’estimation effectuée
+ NE PAS CONFONDRE CHARGE ET DURÉE
« Le travail se dilate jusqu’à remplir le temps disponible »
+ UNITÉ
jour/homme
120
OBJECTIF

EVALUER LA CHARGE
+ SI LES COÛTS ET DÉLAIS SONT FIXES :
On adapte le périmètre aux contraintes.
+ SI LE PÉRIMÈTRE EST FIGÉ :
On accepte d’éventuels dépassements de charge ou délais.
+ SI LE DÉLAIS EST FIXE :
On planifiera différemment les réalisations (lotissement, parallélisation)
On travaillera la priorisation des exigences/besoins/travaux/livrables
121
QUADRATURE DU CERCLE
+ LE NIVEAU DE QUALITÉ ATTENDU DANS CERTAINS CONTEXTES
PEUT INFLUER FORTEMENT SUR LE CHIFFRAGE.
Exemple : environnements réglementés, conformité réglementaire ou à une
norme ISO

EVALUER LA CHARGE
+ COMPLÉTUDE :
Rien n’est oublié
+ HONNÊTE ET RÉALISTE :
Faire abstraction des influences externes
Pas d’excès d’optimisme qui engage toutes les parties prenantes et les conduit à l’échec, en plus de la
déception
+ EXPLICITE :
Ce qui est inclus, ce qui est exclus, les hypothèses de chiffrage, les limites & contraintes
+ CONTINUITÉ :
Plusieurs chiffrages d’un même projet doivent être très proches  crédibilité
+ EXPÉRIENCE :
Capitaliser sur les constats précédents
+ SAVOIR CE QUE L’ON CHIFFRE
Un coût de fabrication en interne
Le prix du projet acheté à un prestataire
122
QU’EST CE QU’UN BON CHIFFRAGE ?

EVALUER LA CHARGE
+EVALUATION INITIALE AU DÉMARRAGE DU PROJET = CHARGE
CONSOMMÉE CONSTATÉE EN FIN DE PROJET
On ne sait vraiment si on a fait un bon chiffrage qu’à la fin du projet
+SAVOIR VIVRE AVEC L’INCERTITUDE TOUT AU LONG DU PROJET
Maîtriser le niveau d’imprécision acceptable
+SE DONNER DES MARGES DE MANŒUVRE ET TOUJOURS
CONNAÎTRE LA VARIABLE D’AJUSTEMENT
Coût - Délais - Périmètre - Qualité
+L’EXPERTISE DU CHEF DE PROJET CONSISTE AUSSI À SAVOIR
PILOTER À CHARGES ET DÉLAIS FIXES
123
QU’EST CE QU’UN BON CHIFFRAGE

EVALUER LA CHARGE
+PLANNING POKER
+ABAQUES – ACTIVITÉS ET LIVRABLES
+ABAQUES – RÉFÉRENTIEL DES EXIGENCES
+MÉTHODE DITE DU « PLANNING »
+EVALUATION DU MARCHÉ
+AUTRES MÉTHODES
COCOMODO
Points de fonction
Cas particulier : complexité du modèle de données
124
MÉTHODES

EVALUER LA CHARGE
+EN COURS DE FORMATION, NOUS PRÉSENTERONS LES
MÉTHODES LES PLUS UTILISÉES.
+NOUS LES METTRONS EN PRATIQUE AUTOURS D’UN JEU.
125
MÉTHODES

EVALUER LA CHARGE
+ ON ÉVALUE UNE CHARGE DE RÉFÉRENCE
Chiffrage de toutes les activités techniques de réalisation / activités opérationnelles
Définir ce qui est inclut dans la charge de référence. Exemple : codage + tests unitaires et tests
de mise au point.
+ PRINCIPES D’ÉVALUATION
 Evaluer la charge de référence de réalisation des activités opérationnelles
 En cas de conformité règlementaire ou à une norme ISO, augmenter la charge de référence à minima de 30%. En cas de
mise aux normes, il arrive que l’on double la charge de référence.
 Charge de conception, pré-étude : à minima 40% de la charge de référence
 Charge de recette, intégration, déploiement : à minima 40% de la charge de référence
 Charge de pilotage et suivi du projet : 20% de la charge de référence
 Rajouter 5 à 15% de provision pour risques aléatoires.
+ LA PLUS PART DES MÉTHODES DE CHIFFRAGE PRÉSENTÉES AFFINENT CES
PRINCIPES.
Toute la difficulté consiste à savoir estimer de façon juste la charge de référence.
126
QUELQUES PRINCIPES ET REPÈRES

EVALUER LA CHARGE
+ SOYONS RÉALISTES
Pas d’excès d’optimisme ou de pessimisme
+ TOUJOURS S’APPUYER SUR L’EXPÉRIENCE DES PROJETS PASSÉS
Capitaliser
Se constituer un référentiel de chiffrage, un historique
+ TOUJOURS GARDER DE LA MARGE
Un projet fait toujours face à des aléas du fait que les activités ne sont pas récurrentes.
+ IDENTIFIER LES POINTS À RISQUES, IDENTIFIER LES ACTIONS DE RÉSORPTION ET
ÉVALUER LA CHARGE ASSOCIÉE
127
RETOURS D’EXPÉRIENCE

EVALUER LA CHARGE
+ PLUS ON PASSE DE TEMPS SEUL SUR UN CHIFFRAGE, PLUS LA CHARGE ÉVALUÉE EST
IMPORTANTE ET PLUS LE CHIFFRAGE EST FAUX
› Sur un projet conséquent, privilégier une première évaluation imprécise effectuée
seul et compléter par une revue collective
+ PLUS LE NOMBRE D’ACTIVITÉS IDENTIFIÉES EST IMPORTANT, PLUS LA CHARGE ÉVALUÉE
EST IMPORTANTE ET PLUS LE CHIFFRAGE EST FAUX
› Ne pas descendre dans un détail trop fin
› Accepter de ne pas avoir la vision complète et finement détaillée au lancement
+ EVITER LE SYNDROME DU « JE ME FAIS PEUR »
+ EVITER LE SYNDROME DU « JE SUIS SUPER CONFIANT »
128

EVALUER LA CHARGE
+UTILISER SON BON SENS
+SAVOIR UTILISER LES EXPERTS, LES « SACHANTS »
+TOUJOURS DOUTER
› Affiner le chiffrage par une revue collective
› Se challenger, revoir ses hypothèses
› Intégrer les risques du projet
› Valider son chiffrage en construisant son planning et en vérifiant la « faisabilité » et
« l’acceptabilité »
129

EVALUER LA CHARGE
+UN CHIFFRAGE CONSIDÉRÉ COMME « TROP ONÉREUX » DOIT AMENER À
REVOIR LE PÉRIMÈTRE :
Eliminer les besoins non prioritaires ou mal définis
Prioriser
Redécouper le projet en phase
+RESTER NEUTRE, NE PAS « PERSONNALISER » L’ÉVALUATION.
On évalue une charge moyenne
Ne pas se poser la question du « qui va faire l’activité » et « quel est son degré d’expertise »
Exemple : Réalisation faite par un expert, donc je réduis ma charge
130

EVALUER LA CHARGE
+IL N’Y A PAS DE CHIFFRAGE JUSTE
Être le plus honnête et complet possible dans son évaluation de la charge
+EN COURS DE PROJET :
» Suivre finement (quotidiennement) les charges consommées.
» Collecter les gains de charges et les réaffecter aux activités plus consommatrices
que prévues
‪ Idéalement, un outil supporte ce suivi.
‪ Ne pas chercher à suivre les charges consommées par des acteurs
externes
» A chacun ses responsabilités
» Suivre le planning de réalisation uniquement >> principe de la boite noire.
131
RESPONSABILITÉS DE L’ÉVALUATEUR

EVALUER LA CHARGE
+L’ORIGINE D’UN DÉPASSEMENT EST SYSTÉMATIQUEMENT :
Une imprécision dans l’évaluation, oubli d’activités, mauvaise estimation, mauvaise anticipation
des risques
Non prise en compte des hypothèses de chiffrage
Mauvaise communication aux acteurs des contraintes de réalisation
Changement des conditions de réalisation du projet : modification de périmètre mal maîtrisée,
difficulté ou risque non anticipé, retard de planning
+TOUT DÉPASSEMENT DE DÉLAIS IMPLIQUE systématiquement UN
DÉPASSEMENT DE CHARGES, À MINIMA DES ACTIVITÉS PROPORTIONNELLES
AU TEMPS.
132
DÉPASSEMENTS

EVALUATION DE LA CHARGE
+L’ÉVALUATION DES CHARGES EST UNE ENTRÉE INDISPENSABLE À LA
RÉALISATION DU PLANNING ET RÉSERVATION DES RESSOURCES
+UNE BONNE PRATIQUE :
Avant l’évaluation des charges, rédiger un planning acceptable de réalisation,
positionner les acteurs
Evaluer la charge (méthode des abaques)
A partir de l’évaluation de la charge, (re)construire un planning et le comparer au
planning initial
Ajuster planning et évaluation de charges
133
CONSTRUIRE LE PLANNING

PLAN PROJET
134
FAIRE LA SYNTHÈSE DU PROJET
12.

PLAN PROJET
+2 NIVEAUX DE PLANIFICATION SUR UN PROJET
Le plan projet  synthèse du projet
Le planning  calendrier

PLAN PROJET
136
DÉFINITION
+CONTRAT ENTRE LE CHEF DE PROJET ET L’ORGANISATION (DIRECTION)
décrit principalement le périmètre du projet, ses livrables, les objectifs qu’il doit
atteindre, les contraintes et les hypothèses du projet, l’organisation à mettre en place
pour atteindre les objectifs et les besoins en ressources humaines et matérielles.
+RÉFÉRENCE À PARTIR DE LAQUELLE LE SUIVI DE PROJET SERA RÉALISÉ.
Disposer d’une référence permet de détecter les écarts par rapport à ce qui a été prévu
Prendre les actions nécessaires pour garder la maitrise du projet.
+POUR LES INTERVENANTS DU PROJET, LE « MODE D’EMPLOI » DU PROJET.

PLAN PROJET
137
CONTENU
+ 4 AXES PRINCIPAUX
La définition du périmètre, du budget et des délais
L’organisation du projet
La stratégie de développement
Les mécanismes de suivi de projet
+ EN COMPLÉMENT
La stratégie d’Assurance Qualité
La stratégie de gestion de configuration
La stratégie de suivi de la sous-traitance
La stratégie de recette
+ EN FONCTION DE L’AMPLEUR DU PROJET OU DE SON ORGANISATION LES ÉLÉMENTS EN
ANNEXE PEUVENT ÊTRE DES DOCUMENTS À PART ENTIÈRE.
plan d’Assurance Qualité, Plan de Gestion de Configuration, Plan de Suivi de de la Sous-traitance,
plan de formation, plan de déploiement, plan d’expérimentation, plan de communication …
Objectifs majeurs du projet :
Coût, Qualité, Délai

PLAN PROJET
138
CONTENU
+ LE CONTEXTE
Une description succincte du produit / système développé par le projet et de son environnement. En particulier lorsque le produit
/ système s’intègre dans un autre produit / système il est nécessaire de comprendre quel rôle joue le produit / système dans
celui de plus haut niveau.
+ LE PÉRIMÈTRE DE TRAVAIL
En lisant ce paragraphe ont doit comprendre quel est le travail à réaliser, quels sont les livrables du projet. Par exemple on peut
trouver la liste des lots de travaux à réaliser.
+ LES OBJECTIFS DU PROJET
Les objectifs du projet, tant en terme de dates de livraisons que d’objectifs de performance et de qualité.
+ LES HYPOTHÈSES ET LES CONTRAINTES
Les hypothèses (e.g. démarrage à t0 = dd-mm-yy) et contraintes (e.g. disponibilité limitée de la plateforme de test) du projet.
+ LES DÉPENDANCES
Les fournitures attendues d'autres projets, du client, de sous-traitants.
+ LES RISQUES
Les principaux risques de ne pas atteindre les objectifs du projet.

PLAN PROJET
139
CONTENU : SYNTHÈSE DES COÛTS ET DÉLAIS
+ PARMI LES OBJECTIFS DU PROJET, FIGURENT LE COÛT ET LE DÉLAI PLANIFIÉ.
En général, ces données font l’objet d’un chapitre à part entière.
+ IL EST IMPÉRATIF QUE LES INFORMATIONS SUIVANTES SOIENT TRAITÉES
Pour le délai
› La planification des différents jalons (Cf. cycle de vie adopté pour le projet)
› Dans la forme, on utilise souvent un diagramme de Gantt
Pour le coût,
› ON TRAITERA AU MOINS :
› Le chiffrage de l’effort (que nous verrons dans le chapitre Estimation)
› Sa répartition budgétaire en quantité et en valeur selon les règles requises
› Le chiffrage des achats
› La répartition de tous ces coûts dans le temps En général, un projet émarge sur un
budget unique, mais il peut y avoir des
dispositions particulières

PLAN PROJET
140
CONTENU : ORGANISATION DU PROJET
+ LES INTERFACES
L’identification des intervenants extérieurs au projet : cela contribue à une identification exhaustive des contraintes du projet
et des attentes de chacun.
+ LES RÔLES & RESPONSABILITÉS
Les rôles & responsabilités du projet adaptés des rôles standards de l’organisation pour satisfaire les besoins spécifiques du
projet.
La description d’un rôle se fait au travers de :
› L’INTITULÉ
› LES RESPONSABILITÉS
› LES AUTORITÉS
› LES COMPÉTENCES REQUISES
+ LES MÉCANISMES DE COMMUNICATION
Les mécanismes de communication entre les membres de l’équipe projet et avec les intervenants extérieurs au projet
L’utilisation d’un organigramme permet de montrer les flux de communication en terme de reporting et également les flux de
communication « techniques ».
+ LA MATRICE D’ALLOCATION DES RÔLES AUX INDIVIDUS DU PROJET
Cette matrice a pour objectif d’allouer les rôles définis aux individus du projet
Lorsqu’un individu ne satisfait pas aux compétences requises par le rôle, un plan d’action (e.g. formations) doit également
être défini.

PLAN PROJET
141
CONTENU : CYCLE DE VIE DU PROJET
+ LE CYCLE DE VIE
Le cycle de vie du projet adapté du cycle de vie standard de l’organisation pour satisfaire les
besoins spécifiques du projet.
+ LES DISPOSITIONS SPÉCIFIQUES
La stratégie de mise en œuvre des processus et les adaptations des processus standards aux
spécificités du projet.

PLAN PROJET
142
SUIVI ET REVUE
+ MÉCANISMES DE SUIVI ET DE REVUE DU PROJET
L’identification des jalons (en cohérence avec le cycle de vie choisi) pour lesquels une revue
formelle sera réalisée pour marquer l’avancement du projet.
Comités de pilotage et comités de projet  planifier à priori toutes les réunions de suivi sur la
durée complète du projet
+ MÉCANISMES D’ALERTE ET ESCALADE EN CAS DE CRISE, CONFLIT MAJEUR, PRISE DE
DÉCISION STRATÉGIQUE
+ GESTION DE LA DOCUMENTATION
Les dispositions pour gérer la documentation du projet.

PLAN PROJET
143
PRÉSENTER LE PLAN PROJET : RÉUNION DE LANCEMENT INTERNE
+UNE RÉUNION DE LANCEMENT FOURNIT LES BÉNÉFICES SUIVANTS :
Instaurer une identité d’équipe ;
Partager les objectifs et l’orientation du projet ;
Partager les connaissances ;
Développer de meilleures relations humaines et une intercompréhension conduisant à une
confiance mutuelle.
+LA RÉUNION DE LANCEMENT
Moyen d’obtenir l’engagement des membres du projet sur le Plan Projet. Pour cela la
communication doit avoir lieu dans les deux sens, par exemple :
Le plan projet est présenté à l’équipe ;
Le retour de l’équipe est pris en compte.

PLAN PROJET
144
+ LA RÉUNION DE LANCEMENT PERMET DE MOTIVER LES ÉQUIPES :
+ UN OBJECTIF CLAIR ET UNE DIRECTION CLAIRE DE LA PART DU CHEF DE PROJET
AIDENT LES MEMBRES DE L'ÉQUIPE À SE SENTIR ENGAGÉS :
Un but à atteindre facilitera la reconnaissance du travail accompli.
+ LES MEMBRES DE L’ÉQUIPE DOIVENT POUVOIR SE RENDRE COMPTE DE CE QUE LE
PROJET APPORTE :
A eux-mêmes
A l’équipe
A l’organisation
Aux clients, utilisateurs
 Montrer la valeur. Faire naître un sentiment de fierté et d’appartenance.

PLAN PROJET
145
+ DONNER LA VISION DU PROJET : OBJECTIF, PHASES, PLANNING, LOTS…
+ ENUMÉRER ET DISCUTER LES CRITÈRES DE SUCCÈS DU PROJET
+ METTRE EN PLACE UNE CHARTE DE COMMUNICATION ET DE FONCTIONNEMENT DE
LA COLLABORATION DE L’ÉQUIPE
+ DÉFINIR EXACTEMENT ET CLAIREMENT CE QUE CHACUN PEUT ATTENDRE D’AUTRUI
+ DIVISER LE TRAVAIL EN LOTS ET ATTRIBUER LES LOTS
+ FAIRE DISCUTER LES MEMBRES DE L’ÉQUIPE DES INTERCONNEXIONS ENTRE LEUR
TRAVAIL
Demander aux personnes dont les fonctions sont interdépendantes d’examiner leurs points de
collaboration
+ DISCUTER DES POINTS QUI POURRAIENT FAIRE ÉCHOUER LE PROJET, DEMANDER
AUX MEMBRES DE L’ÉQUIPE D’IDENTIFIER LES RISQUES ÉVENTUELS ET LA MANIÈRE
DE LES CONTRER

13.

147
PLANIFIER  CALENDRIER DU PROJET
+ GANTT
Chronologie des étapes du projet (wbs)
Dates, charge
Ressources
Modes de planification (ms-project)
› DÉBUTAU PLUS TÔT
› DÈS QUE POSSIBLE
› FIN AU PLUS TARD
+ PERT
Liens entre étapes
Dépendances
Chemin critique
+ EXEMPLES PRÉSENTÉS PAR LE FORMATEUR

+ ACTIVITÉS
+ LIVRABLES
+ EXIGENCES ET FONCTIONNALITÉS À METTRE EN ŒUVRE
+ CHARGE EN J/H ASSOCIÉE
+ DÉLAIS
+ CONTRAINTES
+ …
148
SE DONNER LA VISION DU PROJET

+ CONSTRUIRE LE WBS (WORK BREAKDOWN STRUCTURE)
Découper l'ensemble du travail à accomplir en sections gérables
149
STRUCTURER LE PROJET

+PROJET ET SOUS-PROJET
Un projet complexe peut se décomposer en plusieurs sous-projets, traités par différentes équipes
mais pilotés globalement par un seul chef de projet
Concerne généralement les programmes complexes ayant une durée longue.
+PHASE
Pour pleins de raisons techniques ou organisationnelles, il peut être décidé de découper un projet en 2
phases successives dans le temps. Chaque phase sera alors traitée isolément l’une après l’autre.
150
STRUCTURER LE PROJET - LOTIR

+LOT
Un projet est souvent découpé en LOTS
Il existe 2 modes de découpage en LOTS
1er mode : Lotissement avec une vision « Architecte »
› Dans cette vision, le lotissement est vu comme un moyen de suivre l’avancement de
chaque livrable. On distingue généralement un lot Conception, un lot Architecture, un lot
Pilotage, un lot Recette.
› Ce mode de lotissement est intéressant si plusieurs équipes/fournisseurs réalisent
chaque lot. Cela vous permet de contrôler les productions. Si ce n’est pas le cas, préférer
un découpage par livrables avec des jalons et WBS, plus simple.
151

+LOT
2d mode : Lotissement avec une vision « Développement de solutions
fonctionnelles »
› Le produit à construire est décomposer fonctionnellement (voir les documents
décrivant la construction d’un PBS)
› Pour chaque fonction est définie une criticité permettant d’ordonnancer la
réalisation des fonctionnalités.
› Le découpage est donc effectuée par fonctionnalités de l’outil. Chaque lot
comprendra un nombre restreint de fonctions et produira les livrables techniques
et projet attendus.
› L’intérêt de ce mode de découpage :
Décomposer un problème complexe en une succession de problèmes plus simples
Apporter plus rapidement des « résultats » tangibles au métier
Reporter la réalisation d’exigences ou fonctionnalités moins bien définies.
152

+ITERATION
Vous pouvez mettre en place un projet itératif (ou agile), quelque soit le mode de
découpage précédent (sous-projet, phases, lots…)
Une itération est un moyen de construire rapidement un produit en enchainement
rapidement des phases de conception, développement, recette, mise en production.
Le produit est conçu « collectivement ».
La présence du product-owner est requise à chaque itération pour définir le contenu de
l’itération et valider sa réalisation.
153

154
STRUCTURER SON PROJET - UTILISATION COMBINÉE DES OUTILS
PBS (QUOI FAIRE)
• Décrire les produits techniques
et documentaires à fabriquer
• Décrire les liens entre les sous-
produits
• En lien avec le référentiel des
exigences
Décomposition technique
WBS (COMMENT FAIRE)
• Décrire les étapes de fabrication
• Décrire les livrables
• Décrire les responsabilités
• Planifier et suivre l’avancement
des livrables
Planning & jalons
Rappel
Doublon de page !

CONSTITUER SON ÉQUIPE
GÉRER LES RESSOURCES HUMAINES
14.

+ LA CONSTITUTION DE L’ÉQUIPE EST UNE SOURCE DE MOTIVATION OU AU CONTRAIRE
DE DIFFICULTÉS POUR L’ÉQUIPE
Être vigilant sur les « bons mélanges »
Positionner les personnes sur leurs points forts
Eviter les choix par « défaut ». Dans ce cas, réadapter les activités et tâches avec l’équipe et
organiser les formations
156
DU BON SENS
« Tout le monde est un génie ; mais si vous jugez un poisson sur ses capacités
à grimper à un arbre, il passera sa vie à croire qu’il est stupide »
A. Einstein

+ COMPÉTENCES INTERPERSONNELLES
• « Compétences non techniques », « Soft-skills »  notre capacité à interagir avec autrui
• Nécessaires pour la cohésion de l’équipe
• Empathie, influence, créativité, « facilitation », débrouillardise, organisation…
+ FORMATION
• Toutes les activités destinées à améliorer les compétences des membres de l’équipe de projet
• Formelle ou informelle
• Suivi d’un cours, e-learning ou coaching
+ ACTIVITÉS DE DÉVELOPPEMENT DE L’ESPRIT D’ÉQUIPE
• D’un sujet abordé en cinq minutes au cours d’une réunion de revue jusqu’à un séminaire organisé à l’extérieur par
des professionnels.
• Aider les membres individuels de l’équipe à travailler ensemble de façon efficace.
157
COMPÉTENCES ET FORMATION

CONSTITUER L’ÉQUIPE PROJET
158
5 PHASES
Efficacité
Temps
Constitution
Normalisation
Adaptation
Performance
optimale
Dissolution de
l’équipe projet
FIN
Positionnement
Turbulences
Ajustements

+ ELABORER LA MATRICE DES COMPÉTENCES
159
PLAN DES RESSOURCES HUMAINES
Domaines
Modules Wireframe
Graphical
design
HTML
Accesibilité
Intégration
continue
Release
note
Gestionde
configuratio
n
Build,
packaging
&
installation
Testsde
performanc
e
Complexité technique 3 3 3 3 3 3 3 3 3
Complexité
fonctionnelle
3 3 3 3 3 3 3 3 3
La charge (taille) 3 3 3 3 3 3 3 3 3
Criticité technique 3 3 3 3 3 3 3 3 3
Criticité fonctionnelle 3 3 3 3 2 3 3 3 3
Couverture de test
Critique
P Criticité du module 3 3 3 3 3 3 3 3 3
n 1 Said EL ALAOUI 2 2 0 0 3 0 1 0 0
n 1 Mohamed Yassine 0 0 2 0 0 2 0 1 0
0 1 Ibtissam Ghazi 0 0 0 0 0 0 0 0 0
DOMAINE AGENCY DOMAINE SUPPORT

+ ELABORER LE PLAN DE CHARGE ET RÉSERVER LA DISPONIBILITÉ DES PERSONNES
160
PLAN DES RESSOURCES HUMAINES

FAIRE VIVRE SON ÉQUIPE PROJET
+ ORGANISER DES RITUELS : RÉUNION HEBDOMADAIRE, QUOTIDIENNE
+ DONNER LA PAROLE À TOUS
+ RESPONSABILISER LES ACTEURS

GÉRER LES CONFLITS
15.

GÉRER LES CONFLITS
+ LES CONFLITS NAISSENT D’INTÉRÊTS DIVERGENTS,
DE PERTE DE REPÈRES
Un projet engendre de la pression
+ TOUT PROJET A SA « PÉRIODE DE CRISE »
+ EN DÉBUT DE PROJET, CHAQUE PARTIE-PRENANTE A :
Rêvé sa vision du projet
Définit ses enjeux personnels et sa vision des enjeux
collectifs
+ AU COURS DU PROJET, DES ÉVÉNEMENTS, DÉCISIONS
VONT
Contredire la vision « idyllique » du début de projet
Obliger à des concessions
Les réalisations peuvent être en conflit avec la vision initiale
+ SEULE SOLUTION
Communiquer, rappeler en permanence les enjeux et
objectifs du projet.
163
D’OÙ VIENNENT LES CONFLITS ?
Utilisateurs
Clients
Membres de
l’équipe
Direction
Organisation
Chef de
projet
Direction du
projet

GÉRER LES CONFLITS
+ LES CONFLITS NAISSENT D’INTÉRÊTS DIVERGENTS,
DE PERTE DE REPÈRES
Un projet engendre de la pression
+ TOUT PROJET A SA « PÉRIODE DE CRISE »
+ EN DÉBUT DE PROJET, CHAQUE PARTIE-PRENANTE A :
Rêvé sa vision du projet
Définit ses enjeux personnels et sa vision des enjeux
collectifs
+ AU COURS DU PROJET, DES ÉVÉNEMENTS, DÉCISIONS
VONT
Contredire la vision « idyllique » du début de projet
Obliger à des concessions
Les réalisations peuvent être en conflit avec la vision initiale
+ SEULE SOLUTION
Communiquer, rappeler en permanence les enjeux et
objectifs du projet.
164
D’OÙ VIENNENT LES CONFLITS ?
Utilisateurs
Clients
Membres de
l’équipe
Direction
Organisation
Chef de
projet
Direction du
projet
Impatience, pas assez
vite
Espoirs déçus
Divergences avec
l’organisation
Trop de changements = on
avance pas, instabilité,
agacement, dévalorisation
Routine = Ennui
Pas de vision globale
Pression du sponsor : quand est ce
que je réalise mon « bénéfice »
Ne suis-je pas en train d’investir en
pur perte ?
Absorber la pression
Arbitrer ou faire arbitrer
Se concentrer sur ses
valeurs, son plan projet
Tout tracer
Communiquer

MAÎTRISER LES RISQUES DU PROJET
16.

+ RISQUES INTERNES DES PROJETS DE CONSTRUCTION
http://documents.irevues.inist.fr/bitstream/handle/2042/37262/1370.pdf
166
RISQUES CONNUS

+ UN ÉVÉNEMENT QUI NE S’EST PAS ENCORE PRODUIT/RÉALISÉ MAIS DONT ON
REDOUTE LES EFFETS ESTIMÉS NÉFASTES
+ TOUJOURS FORMULER LE RISQUE
La situation existante
L’événement redouté ou la situation redouté
(I) Les dégâts potentiels. Evalués en termes de délai, charge ou perte de qualité
(O) La probabilité d’occurrence
(P) Eventuellement, la proximité du risque
(S) La sévérité = (I) x (O) x (P)
Le plan d’action de mitigation si la sévérité atteint un certain seuil.
+ MITIGATION :
Supprimer le risque
Ramener le risque ou ses conséquences à un niveau acceptable  cas par cas. Estimation humaine.
+ TOUJOURS APPORTER UNE ÉVALUATION DU RISQUE ET UN PLAN D’ACTIONS
167
DÉFINITION

+PLUSIEURS TYPES DE RISQUES SUR UN PROJET AVEC DES ENJEUX
DIFFÉRENTS ET DES NIVEAUX DE SUIVI DIFFÉRENTS
› OPÉRATIONNELS OU STRATÉGIQUES
Risques opérationnels : difficultés techniques limité au projet
Risques stratégiques : l’image de la société est altérée
‪ Exemples : impacts sur le SI des clients (perte de données), perte de chiffre
d’affaires, mauvaise satisfaction client…
› INTERNES OU EXTERNES
Risques internes au projet  non atteinte ou atteinte partielle des objectifs. Exemple :
perte d’une ressource
Risques externes au projet : dégâts collatéraux  régression, perte de fonctionnalité,
cascades de difficultés ou d’actions à mener
› RISQUES À FAIRE ET RISQUES À NE PAS FAIRE
168
TYPES DE RISQUES

+ PROJET
Moyens, ressources humaines, démarche,
planification, management…
+ CONTRACTUEL, JURIDIQUE
Relations avec des prestataires externes,
contenu du contrat…
+ FONCTIONNEL :
Fonctionnalités du produit, ergonomie,
interfaces, service rendu à l'utilisateur…
+ TECHNIQUE :
Architecture, performances, technologies,
matériels et logiciels de base, configuration des
postes de travail…
169
RISQUES CONNUS
+ ORGANISATIONNEL :
Structures, procédures, acteurs…sous-estimer le
temps nécessaire pour dresser une cartographie
fiable de l’existant
+ AUTRES
Voir trop grand
Pas de sponsor ou un sponsor peu engagé ou sans
pouvoir
Risques intrinsèques à la gestion de projet
+ NE PAS OUBLIER LES RISQUES EXTERNES
Le plus grand risque sur un
projet, c’est la mauvaise
anticipation des risques et
événements aléatoires !

+ EXIGENCES, BESOINS, CAHIER DES CHARGES
Complétude, compréhension, faisabilité,
incohérences, implication du métier ou des
utilisateurs, stabilité, changements, interfaces
+ SOLUTION TECHNIQUE
Solution du marché, degré de dépendance avec un
éditeur ou un intégrateur, compétence, expérience,
expertise
+ TESTS
Stratégie de tests, préparation, organisation des
campagnes de tests, délais et engagements de prise
en compte et de réponse
+ ENVIRONNEMENTS TECHNIQUES
Développement, recette, pré-production, intégration,
production
170
REX - SOURCES DE RISQUES
+ ENVIRONNEMENTS TECHNIQUES
Développement, recette, pré-production,
intégration, production
+ QUALITÉ DE L’APPLICATION REPRISE
+ REPRISE DES DONNÉES
Validation de la reprise, perte de données
potentielle, transformation des données
+ SÉCURITÉ DU SI
Environnements, machines, réseau
Anonymisation des données

+ MAUVAISE QUALITÉ DU PRODUIT
+ MAUVAISE QUALITÉ OU PERTE DE
DONNÉES
+ SYSTÈME ERRONÉ OU INUTILISABLE
+ DIFFICULTÉ D'INTÉGRATION AVEC LES
AUTRES SYSTÈMES
+ REJET DU SYSTÈME PAR LES
UTILISATEURS
+ DÉFICIENCES DE PROPRIÉTÉS NON
FONCTIONNELLES
sécurité, maintenabilité, efficacité, rentabilité…
171
IMPACTS CONNUS
+ DÉMOTIVATION DE L'ÉQUIPE
+ RETARDS DANS LA LIVRAISON
+ COÛTS IMPRÉVISIBLES
+ COÛTS DÉMESURÉS
+ COÛT DE MAINTENANCE ÉLEVÉ
+ DÉGRADATION DE L'IMAGE DU SERVICE
Incidence de l'échec sur le fonctionnement de
l’entité
Non acceptation du service, produit

+ EQUIPE PROJET
Disponibilité, expérience, expertise, motivation, pilotage de la sous-traitance, équipe répartie
+ PILOTAGE
Indicateurs, planning, gestion de projet, gestion de configuration, contrat, validation
documentaires et livrables
+ BUDGET
Cohérence avec les besoins, prise en compte des changements
+ APPEL À DES SOUS-TRAITANTS
Préparation puis suivi de mission, vérification de la solidité financière
172
SOURCES DE RISQUES

+ EXEMPLE : LE NIVEAU DE RISQUE EST MESURÉ SELON 2 FACTEURS
PRINCIPAUX
Probabilité d’occurrence : 0 à 4
Impact du risque : 1 à 3
Proximité du risque : 1 à 3 (facteur facultatif, selon le contexte)
+ LA NOTION DE PROBLÈME
Danger immédiat pouvant aller jusqu’à
» La remise en cause du projet.
» Sur certaines activités particulière : accidents graves, décès, blessures,
dommages matériels importants
173
CLASSIFICATION
1 2 3
0 0 (bas) 0 (bas) 0 (bas)
1 1 (bas) 2 (bas) 3 (medium)
2 2 (bas) 4 (medium) 6 (fort)
3 3 (medium) 6 (fort) 9 (critique)
4 Problème Problème Problème
Probabilité
Impact

+ SUIVANT LE NIVEAU DE RISQUE ET SON IMPACT, UN PLAN D’ACTIONS EST MIS EN
ŒUVRE
174
MISE EN ŒUVRE D’UN PLAN D’ACTIONS
Repérer les risques
Hiérarchiser les risques
Elaborer un plan d’action de
prévention
Contrôler l’efficacité des actions
menées et leur pérennité
Suppression
Réduction
Substitution
Protection
Vérifications régulières
tout au long du projet

BILAN PROJET
17.

Les fondamentaux de la gestion de projet

Les fondamentaux de la gestion de projet

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Les fondamentaux de la gestion de projet

Ähnlich wie Les fondamentaux de la gestion de projet (20)

Mehr von COMPETENSIS

Mehr von COMPETENSIS (20)

Les fondamentaux de la gestion de projet