La version 2015 de la conférence sur la chefferie de projet présentée aux étudiants de l'Université Lyon1. La présentation met l'accent sur la communication, l'anticipation et l'identification des risques quelque soit la méthodologie utilisée, cycle en V ou agile.

1. La gestion de projets
Informatiques
@loiccharpentier
https://fr.linkedin.com/in/loiccharpentier
09/06/2015

2. PRÉSENTATION

3. Qui suis-je ?
• A l’origine : Ancien étudiant issu de l’IUT A Lyon 1
• Hier : Développeur, Chef de projet, Responsable de service, …
• Aujourd’hui : Responsable Marketing Produit
« L’expérience importe moins que la passion et la motivation. »

4. POURQUOI LA GESTION DE PROJET ?

5. Coordonner l’effort
Périmètre
Budget Délai
Qualité

6. GARANTIR LA CIRCULATION
D’INFORMATION
• Interlocuteurs :
– Client
– Prestataire
– Equipe fonctionnelle
– Instance de pilotage
– Direction

7. LE RÔLE DU CHEF DE PROJET

8. Appliquer le cadre d’exécution
Consultation/AO
Expression
du besoin
L'étude
d'opportunité
L'étude de
faisabilité
L'étude détaillée
L'étude
technique
Cahier des
charges Propale
Formalisation du besoin
Quelque soit la méthodologie projet, il y a toujours un cadre !

9. Intégrer tous les aspects d’un projet
• Gestion de ressources humaines
– Disponibilités des collaborateurs
– Compétences des collaborateurs
• Gestion de ressources matérielles
– Serveurs, supports physiques,
– Licences logicielles, …
• Gestion de ressources financières
– Gestion des commandes externes
– Gestion des avenants
• Gestion de la communication projet
– Gestion des plannings
– Gestion des comptes rendus
– Gestion des comités de pilotage
– Gestion de la documentation projet
• Gestion de la relation client
– Réunion projet
– Contact téléphonique
– Avant-vente
– ….

10. Être à l’écoute
• Anticiper les événements,
un pilotage proactif plutôt qu’un contrôle tardif
• Être flexible & réactif,
durant les premières phases du projet pour pouvoir prendre en
compte les modifications
• Avoir une vision globale et
systémique,
pour apporter des solutions adaptées à tous les problèmes.

11. Identification des risques
1. Identifier les risques du projet
2. Identifier la gravité des risques
3. Identifier la probabilité d’apparition
4. Identifier les mesures préventives
5. Identifier les mesures correctives

12. DANS QUEL CONTEXTE

13. De lourdes responsabilités
Equipe projet
• Exigence de clarté
• Demande de souplesse
• Exigence de communication
Client
• Respect des délais
• Respect de la qualité
• Respect du cadre financier
• Demande de fonctionnalité
• Exigence de visibilité
Prestataire
• Demande d’information
• Demande de souplesse
• Exigence d’information
• Respect du cadre financier
Direction
• Respect du cadre financier
• Respect du relationnel
• Tenu du planning
• Impératif d’activité

14. De nombreuses variables
• La charge : nombre de personnes travaillant sur le projet par type (interne ou externe),
par unité de temps, par phase du projet.
• Le coût : masse salariale, formation, matériels, frais annexes (téléphone, fournitures, etc).
• L’avancement : – tâches réalisées, tâches à venir ; – jalons ; – date de fin initiale, date de
fin réelle ; – nombre de tâches terminées par rapport au nombre de tâches prévues ; –
avancement du projet (en pourcentage) ; – retard de validation et de livraison des
livrables.
• Les ressources : nombre de jours de formation du personnel, d’arrêt maladie et
d’absence.
• Le suivi de réalisation : charge prévisionnelle et effective de réalisation et délai de
résolution d’un problème.
• Le suivi de la mise en oeuvre du projet : charge nécessaire pour le démarrage de
l’application sur un site et dates effectives de démarrage.
• La maintenance : nombre de demandes de maintenance corrective, évolutive.

15. Une reconnaissance parfois difficile
Equipe projet
« le chef de projet ne produit pas et ne comprend pas…»
Client
«La gestion de projet est-elle nécessaire ? »
Prestataire
Direction
« le chef de projet doit tenir nos engagements
Source :www.dilbert.com

16. TYPOLOGIES DE PROJETS

17. Projets en régie
– Le prestataire s’engage
contractuellement à un
engagement de moyen.
– Pourquoi ?
– Quel risque ?

18. Projets au forfait :
– Le prestataire s’engage
sur la base d’un montant
forfaitaire à un
engagement de résultat.
– Pourquoi ?
– Quels risques ?

19. EN PRATIQUE

20. Cas client
• Création d’un site internet
de publication de
contenu éditoriaux et
d’animations scientifiques
à destination des
enfants/ados
• Contexte :
– Démarrage du projet le 15 mai 2012
– Client : Service communication d’un gros industriel
– Expertise : Le client dispose d’un expert en animation
scientifique
– Existant :
• Une version 1 du site est déjà existante
• Un prototype d’une v2 du site a déjà été réalisée
mais laissé en l’état.
– Les animations scientifiques doivent être sonorisée (voix-
off)
– Le client souhaite être autonome sur la mise à jour
Quels risques (questions) identifiez vous ?
En combien de temps ce projet peut-il être mené sachant
que la charge est estimée à 40 j/h ?

21. L’analyse des risques
• Risques potentiels :
– Démarrage fin mai : proximité des congés d’été, indisponibilité potentielle des
interlocuteurs et de l’équipe projet.
– Gros industriel / Service de communication : Service potentiellement très sollicité, les
retours clients peuvent donc être longs.
– Service de communication : Sensible à l’image et au contenu éditorial, le respect de la
charte graphique et la qualité des textes doivent être irréprochables.
– Site existant : la comparaison avec le site existant est inévitable, les forces et faiblesses sont
à étudier en amont.
– Prototype v2 non finalisé : le projet a été stoppé ? Quels ont été les freins ? Est-ce un échec
? Y’a-t-il des a priori ?
– Voix-off : le client a-t-il conscience du cout d’un acteur voix-off ? Comment ont été
réalisées les voix-off du prototype ?
– Le public est enfant/ado : les deux publics sont très différents, le client doit potentiellement
prévoir deux accès afin de ne pas s’adresser de la même manière à ces deux cibles.
– Le client veut être autonome : Quel est sa compétence en informatique ? La solution doit
être adaptée à son niveau ? Quelle doit être sa marge d’autonomie.

22. Un exemple

23. EN PRATIQUE

24. Méthodologie PROJET
Sources : les schémas appartiennent à leurs auteurs.

25. METHODOLOGIE PROJET
Il n'y a pas de bonnes ou de mauvaises méthodes.
Chaque projet a ses spécificités qui conduisent à
définir la méthode la moins mauvaise qui résulte le
plus souvent du dosage subtil de plusieurs
méthodes.

26. Bon projet !
Et bon courage…