Más contenido relacionado La actualidad más candente (20) Similar a Les fondamentaux de la gestion de projet (20) Les fondamentaux de la gestion de projet1. 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
2. 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
3. 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é
8. 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
9. 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
10Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+ 18. FACTEURS CLÉS DU SUCCÈS
12. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
13. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
14. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
15. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
16. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
17. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
18. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
19. MATRIOCHKA
20
PROGRAMME – PORTEFEUILLE DE PROJETS – PROJET – CHANTIER- ACTIVITÉ
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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
20. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
21. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
22. 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
23. 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
24. 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
© SQLI GROUP – 2014 chdessus@sqli.com Décembre 2014
25. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
Source : hakanforss.wordpress.com
26. 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
© SQLI GROUP – 2014 chdessus@sqli.com Décembre 2014
28. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
29. 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écembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
Développement de centres de
services axés sur un ou plusieurs
processus majeurs dont ils assurent
la responsabilité : manager du
processus
32. 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
33. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
34. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
35. 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 ?
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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
36. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
Périmètre Budget
38. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
39. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
40. QUI EST MON CLIENT ?
41
QUI PAYE ?
© SQLI GROUP – 2014 chdessus@sqli.com
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
41. ACTEURS DU PROJET
42
PARTIES-PRENANTES (SOURCE : BABOK 2)
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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
42. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
43. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
45. AMÉLIORER LES PRATIQUES
+ 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
46. AMÉLIORER LES PRATIQUES
+ 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
© SQLI GROUP – 2014 chdessus@sqli.com
+ 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
47. AMÉLIORER LES PRATIQUES
48
FIABILISER ET METTRE SOUS CONTRÔLE
© SQLI GROUP – 2014 chdessus@sqli.com
+ 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
48. AMÉLIORER LES PRATIQUES
+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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
49. AMÉLIORER LES PRATIQUES
+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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
Echec = non atteinte des objectifs et engagements initiaux
Qualité, Coût, Délais, Périmètre
50. AMÉLIORER LES PRATIQUES
+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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
52. 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
PROPOSITION DE VALEUR
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
53. CADRER LE PROJET
54
BÉNÉFICES : UTILITÉ ET GARANTIE – SOURCE : ITIL V3 2011
© SQLI GROUP – 2014 chdessus@sqli.com
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
54. 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
PROPOSITION DE VALEUR
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
Achat Installation Implémentation
Maintenance Réparations Mises à jour
Services Support Sécurité
Formation
Arrêt du service
Mise au rebut
Recyclage
Déconstruction
55. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
Service
rendu
Fonctionnalité - Utilité
56. CADRER LE PROJET
+ SUR LES PROJETS COMPLEXES, NE PAS HÉSITER À FORMALISER LA PROPOSITION DE
VALEUR
57
DOSSIER DE CADRAGE
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
57. DÉMARCHE DE PILOTAGE ET
CONDUITE DE PROJET
58
MÉTHODE(S)
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
6.
58. PILOTAGE & CONDUITE DE PROJETS
59Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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
59. PILOTAGE & CONDUITE DE PROJETS
+ 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écembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
60. PILOTAGE & CONDUITE DE PROJETS
+ 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
« 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
61. PILOTAGE & CONDUITE DE PROJETS
+ 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
62. PILOTAGE & CONDUITE DE PROJETS
+ PRINCE 2
63
STANDARDS
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+ PMBOK
Faux-ami
Planning ≠ Scheduling
Cycle de vie ≠ Calendrier
(Phases, Livrables) (Gantt, Pert)
63. PILOTAGE & CONDUITE DE PROJETS
64
EXEMPLES – EXPÉRIENCE DE MISE EN ŒUVRE DE DÉMARCHES
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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.
64. PILOTAGE & CONDUITE DE PROJETS
+ 8 ÉTAPES
65
MÉTHODE GÉNÉRIQUE
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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
65. PILOTAGE & CONDUITE DE PROJETS
+ 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)
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
Itération 1 Itération 2 Itération 3
66. PILOTAGE & CONDUITE DE PROJETS
67
DÉFINIR – CADRER – SÉCURISER
DÉCIDER
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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
67. 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
© SQLI GROUP – 2014 chdessus@sqli.com
© SQLI GROUP – 2014 chdessus@sqli.com
68. PHASE «PRÉPARER»
69Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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é
69. PHASE «RÉALISER»
70Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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
70. PHASE «DOCUMENTER»
71Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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.
71. 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
72Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
72. PHASE «EFFECTUER LA TRANSITION»
73Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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.
73. PHASE «CONTRÔLER L’ATTEINTE DES OBJECTIFS »
74Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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
74. PHASE «FERMER»
75Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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
75. PHASE «SURVEILLER CONDUIRE & PILOTER»
76Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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 »
76. 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.
77Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
77. FOCUS SUR LES DÉMARCHES
AGILES & ITÉRATIVES
78
MÉTHODE(S)
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
7.
78. MÉTHODE(S) AGILE(S)
79
VALEURS DU MANIFESTE AGILE
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+ 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
79. + 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
MÉTHODE(S) AGILE(S)
80
IDÉES REÇUES À COMBATTRE
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
80. MÉTHODE(S) AGILE(S)
81
DÉFINITION
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
« 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
81. MÉTHODE(S) AGILE(S)
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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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
82. MÉTHODE(S) AGILE(S)
83
VUE D’ENSEMBLE
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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
83. MÉTHODE(S) AGILE(S)
84
COMMENT METTRE EN ŒUVRE L’AGILITÉ
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+ 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
84. 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
85. 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
86. 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
87. MÉTHODE(S) AGILE(S)
+ 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+ 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
88. MÉTHODE(S) AGILE(S)
89
RÔLES ET RESPONSABILITÉS « PRODUCT OWNER »
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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
89. MÉTHODE(S) AGILE(S)
90
RÔLES ET RESPONSABILITÉS « SCRUM MASTER »
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
Chef de
projet
Architecte
Responsable
technique
SCRUM = MÊLÉE
blog.xebia.fr/2013/07/24/dessine-moi-un-scrum-
master
90. MÉTHODE(S) AGILE(S)
+ 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
RÔLES ET RESPONSABILITÉS
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+ 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
91. MÉTHODE(S) AGILE(S)
+ 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
RÔLES ET RESPONSABILITÉS
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+ 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
92. MÉTHODE(S) AGILE(S)
93
CRITÈRES D’ÉLIGIBILITÉ
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+ 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
94. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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
95. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
Source : http://www.cigref.fr
96. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
Vision stratégique, atteinte des objectifs et enjeux du projet
Vision opérationnelle, avancement des phases et étapes du projet
98. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
99. DÉFINITION D’UNE EXIGENCE
100
SOURCE : WWW.IIBA.ORG BABOK : BUSINESS ANALYSIS BOOK OF KNOWLEDGE
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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 exigences
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…
Analyse des exigences
100. DÉFINITION D’UNE EXIGENCE
101
SOURCE : WWW.IIBA.ORG BABOK : BUSINESS ANALYSIS BOOK OF KNOWLEDGE
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+ UN RÉFÉRENTIEL DÉDIÉ AUX EXIGENCES ET À LA « BUSINESS ANALYSIS »
101. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
103. EXPRESSION DES BESOINS
+ LE DEMANDEUR EST ASSEZ LIBRE DE
DÉCRIRE
› SITUATION ACTUELLE
› SITUATION FUTURE SOUHAITÉE
› CONTRAINTES, DÉPENDANCES CRITIQUES
› BUDGET, DÉLAIS
104
DIALOGUE
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+ CELUI QUI REÇOIT LA DEMANDE
› S’ASSURE DE L’EXHAUSTIVITÉ DES BESOINS
› STRUCTURE LES BESOINS
› S’ASSURE DE SON ÉVALUATION ET
VALIDATION
104. EXPRESSION DES BESOINS
+ 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
Validation
105. EXPRESSION DES BESOINS
+« 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
http://fr.wikipedia.org/wiki/Modèle_de_Kano
106. EXPRESSION DES BESOINS
+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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
107. EXPRESSION DES BESOINS
+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++
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+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
108. EXPRESSION DES 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
109. EXPRESSION DES BESOINS
110
MÉTHODE DE DÉCOUVERTE DES EXIGENCES
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+ 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
110. STRUCTURER LA SOLUTION
+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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
Le référentiel des
exigences permet
de cartographier
les fonctions
attendues
111. STRUCTURER LA SOLUTION
112
FONCTIONS ATTENDUES DE LA SOLUTION
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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
112. STRUCTURER LA SOLUTION
113
MAÎTRISER LES CONFIGURATIONS
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+ 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
113. STRUCTURER LA SOLUTION
+ 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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
115. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
116. STRUCTURER LES ACTIVITÉS ET LIVRABLES
117
PBS & WBS
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+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.
117. STRUCTURER LES ACTIVITÉS ET LIVRABLES
118
PBS & WBS
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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
118. EVALUER LA CHARGE DE TRAVAIL
119
(EFFORT)
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
11.
119. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
120. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+ 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
121. 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 ?
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
122. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
123. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
124. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
125. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
126. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
127. 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
RETOURS D’EXPÉRIENCE
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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
RETOURS D’EXPÉRIENCE
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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
RETOURS D’EXPÉRIENCE
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
131. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
132. 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
134. PLAN PROJET
135Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+2 NIVEAUX DE PLANIFICATION SUR UN PROJET
Le plan projet synthèse du projet
Le planning calendrier
135. PLAN PROJET
136
DÉFINITION
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+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.
136. PLAN PROJET
137
CONTENU
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+ 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
137. PLAN PROJET
138
CONTENU
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+ 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.
138. PLAN PROJET
139
CONTENU : SYNTHÈSE DES COÛTS ET DÉLAIS
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+ 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
139. PLAN PROJET
140
CONTENU : ORGANISATION DU PROJET
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+ 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.
140. PLAN PROJET
141
CONTENU : CYCLE DE VIE DU PROJET
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+ 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.
141. PLAN PROJET
142
SUIVI ET REVUE
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+ 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.
142. PLAN PROJET
143
PRÉSENTER LE PLAN PROJET : RÉUNION DE LANCEMENT INTERNE
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+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.
143. PLAN PROJET
144
PRÉSENTER LE PLAN PROJET : RÉUNION DE LANCEMENT INTERNE
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+ 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.
144. PLAN PROJET
145
PRÉSENTER LE PLAN PROJET : RÉUNION DE LANCEMENT INTERNE
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+ 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
146. CONSTRUIRE LE PLANNING
147
PLANIFIER CALENDRIER DU PROJET
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+ 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
147. CONSTRUIRE LE PLANNING
+ 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
148. CONSTRUIRE LE PLANNING
+ CONSTRUIRE LE WBS (WORK BREAKDOWN STRUCTURE)
Découper l'ensemble du travail à accomplir en sections gérables
149
STRUCTURER LE PROJET
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
149. CONSTRUIRE LE PLANNING
+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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
150. CONSTRUIRE LE PLANNING
+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
STRUCTURER LE PROJET - LOTIR
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
151. CONSTRUIRE LE PLANNING
+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
STRUCTURER LE PROJET - LOTIR
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
152. CONSTRUIRE LE PLANNING
+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
STRUCTURER LE PROJET - LOTIR
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
153. CONSTRUIRE LE PLANNING
154
STRUCTURER SON PROJET - UTILISATION COMBINÉE DES OUTILS
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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 !
155. CONSTITUER SON ÉQUIPE
+ 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
« 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
156. CONSTITUER SON ÉQUIPE
+ 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
157. CONSTITUER L’ÉQUIPE PROJET
158
5 PHASES
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
Efficacité
Temps
Constitution
Normalisation
Adaptation
Performance
optimale
Dissolution de
l’équipe projet
FIN
Positionnement
Turbulences
Ajustements
158. CONSTITUER L’ÉQUIPE PROJET
+ ELABORER LA MATRICE DES COMPÉTENCES
159
PLAN DES RESSOURCES HUMAINES
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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
159. CONSTITUER L’ÉQUIPE PROJET
+ ELABORER LE PLAN DE CHARGE ET RÉSERVER LA DISPONIBILITÉ DES PERSONNES
160
PLAN DES RESSOURCES HUMAINES
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
160. FAIRE VIVRE SON ÉQUIPE PROJET
+ ORGANISER DES RITUELS : RÉUNION HEBDOMADAIRE, QUOTIDIENNE
+ DONNER LA PAROLE À TOUS
+ RESPONSABILISER LES ACTEURS
161Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
162. 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 ?
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
Utilisateurs
Clients
Membres de
l’équipe
Direction
Organisation
Chef de
projet
Direction du
projet
163. 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 ?
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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
165. MAÎTRISER LES RISQUES DU PROJET
+ RISQUES INTERNES DES PROJETS DE CONSTRUCTION
http://documents.irevues.inist.fr/bitstream/handle/2042/37262/1370.pdf
166
RISQUES CONNUS
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
166. MAÎTRISER LES RISQUES DU PROJET
+ 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
167. MAÎTRISER LES RISQUES DU PROJET
+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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
168. MAÎTRISER LES RISQUES DU PROJET
+ 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+ 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 !
169. MAÎTRISER LES RISQUES DU PROJET
+ 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+ 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
170. MAÎTRISER LES RISQUES DU PROJET
+ 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écembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
+ 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
171. MAÎTRISER LES RISQUES DU PROJET
+ 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
172. MAÎTRISER LES RISQUES DU PROJET
+ 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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
173. MAÎTRISER LES RISQUES DU PROJET
+ 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
Décembre 2014© SQLI GROUP – 2014 chdessus@sqli.com
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