Questions Gestion de projet Flashcards
Mes PRINCIPES de base en gestion de projet?
First principles qui influencent le + mon style de gestion de projet (critères succès)
* principes => règles
a. Livrer valeur, comprendre le succès
* valeur = subjective mais qualité (souvent), qualité > coûts, temps, portée
* succès = perception de la valeur livrée. À GÉRER en plus de livrer le système (ex: Desjardins Java vs objectifs de coûts vs rupture de services)
*** succès organisation + succès individus **
* client “proche” du projet = pas de surprise
* focus sur résultats > façon de faire
b. INDIVIDUS à la base du succès et de la productivité des projets … et de l’organisation
* laisser autonomie, et trouver motivation de chacun pour assurer engagement et croissance à travers le projet
* équilibre individu (engagement, croissance) vs équipe (priorité, action, aider)
* défendre équipe (ext/int)
* travaux = contrat selon compétence, potentiel et engagement de chacun
* communication = comportement fréquent & important. Prioriser pour mep équipe
* assurer un environnement productif/structurant (minimiser les problèmes)
* MON engagement pour donner le ton et motiver
- culture de résultats & rétention
c. Attention à l’APPROCHE/EXÉCUTION: projet efficace utilise approche s’appuyant sur les **acquis et la culture **(comportements) de l’organisation (agile ou pas).
* Les principes sont plus importants que la méthode, mais une méthode minimale est nécessaire pour assurer une prévisibilité
* qualité: corriger les erreurs en aval coûte beaucoup + cher et peut mener à l’échec (perte de productivité)
* Livrer rapidement en priorisant la qualité sur le temps
* itérations ou incréments
* obtenir feedback et s’ajuster
* gérer les attentes, rassurer le client, éviter les surprises
d. S’intégrer dans la vie du produit
* projet = étape (création, évolutions, maintenance, fin de vie)
* comprendre requis d’ops à venir
* qualité/succès: pas seulement solution opérationnelle, mais** bien conçue** (maintenance facile, évolutive/modulable, réutilisation/réutilisable, sécuritaire)
* utiliser mêmes procédures de déploiement, tester la documentation durant le projet
* documentation doit soutenir a) l’exécution du projet b) l’évolution de la solution c) la réutilisation dans l’organisation
x. gp = rôle de leadership
* + loin que valeur
* intégrer 4 principes
Mon STYLE de gestion (direction) de projet?
D’un point de vue de la DIRECTION de projet, donc LEADERSHIP
STYLE = comportement et non pas technique
- Voir style de leadership: projet = exercice de leadership pour un directeur de projet (motivation et croissance des individus = comportements recherchés)
- particularité du leadership en projet
- objectifs = ceux du projet (i.e valeur)
- utilisation de techniques conséquentes pour exécution
- s’appuie sur mes 5 principes de gestion de projet (leadership, valeur&succès, individus, approche et intégration)
LA QUESTION EST SOUVENT POSÉE POUR VALIDER LA FLEXIBILITÉ: style adaptable selon objectifs du projet et maturité de l’équipe (participatif <–> directif)
Comment j’abordes un NOUVEAU projet?
Exercice de leadership critique, pas seulement planification & contrôle
Comprendre le projet à travers filtres de mes principes de GP, et démarrer l’exécution en considérant les risques connus et importants.
a. Comprendre ….
- quelle est la VALEUR attendue?
- hypothèses, besoins, parties prenantes et leur attentes
- ce que sera le SUCCÈS?
- coûts? calendrier? perception du poids de la qualité?
- chaîne de valeur organisation?
- quelle FLEXIBLITÉ requise pour succès?
- des parties prenantes / contractuelle / approche
- profils des INDIVIDUS requis pour succès?
- monter équipe équilibrée (seniors/jeune, experts techno, pilote/po dédié) (–>Q)
- l’APPROCHE imposée/connue (gestion / solution)
- considérer l’expérience et possibilité d’apprendre en projet
- le projet dans CYCLE DE VIE de la solution (implantation, DevOps, maintenance)
b. Planifier et démarrer exécution selon risques + importants (identifiés ci-haut)
- Mitiger risques initiaux (attentes, rigidité contrat, calendrier, cplx, conversion, equipe, env, …)
- ne pas gérer tous les risque: compréhension commune -> maj régulière
- planifier buffer pour dépendances et risques confirmés (–>Q)
- **itération 0 **avec noyau / prototype / standards / croitre équipe sur bases solides (coûts et qualité)
- adresser risques solution en amont
- Débuter travaux dès que possible
- “pacesetting” avec premiers livrables
- préciser planification ensuite
- Planifier exécution selon requis production / planifier par la fin du projet (implantation)
Comment livrer plus RAPIDEMENT un projet?
(ou à moindre coûts)
Si le TEMPS est la priorité
- hypothèse de qualité = critère succès
- # 1 = portée : s’entendre sur l’essentiel (MVP) et limiter les complexité-> souvent (45%) fonctionnalités NON- ou PEU utilisées; lesquelles?
- équipe dédiée (vs matriciel)
APPLICABLE DANS TOUT PROJET en équilibre (temps/portée/ressources)
- réutiliser (livrables, stratégies, code, produits, individus) et fusionner
- avoir un pilote dédié et décisionnel
- trouver des solutions simples pour livrer ce qui est au contrat
- itérer lorsque possible (feedback + fréquent = qualité = confiance)
- limiter l’équipe le + possible pour limiter les interactions et maintenir la qualité (garder experts et “meilleurs”)
- éviter les embûches surprises en adressant les risques dès le départ
- qualité intrégrée à chaque phase, et faciliter les essais à tous les niveaux (données partagées)
- travaux en réserve pour demeurer productif (ex: documentation, données d’essais)
- contrôler délais et qualité des approbations
- environnement et outils performants (en soutien à la tâche)
- soutien administratif
- … ** temps supplémentaire** , mais court terme seulement.
Les coûts de M/O sont généralement les plus importants, donc COÛT = TEMP
Comment gérer/mitiger les RISQUES en projet?
Approche de gestion de risques
FUSION RÉAL #13
APPROCHE ET CONCEPTS:
=> Prendre le leadership
=> objectifs clairs pour l’équipe = gestion de risque implicite
=> être réceptif en tout temps: “Qu’est-ce qui pourrait aller mal?”
- Ne pas viser à gérer tous les risques
-> faire un effort significatifs pour identifier et mitiger les risques en début de projet, avec les yeux de tous
-> et reconnaître qu’il y aura des inconnus inconnus qui surviendront, et conserver une marge $ et temps pour les absorber - Après un exercice initial, un suivi régulier permettra de mettre à jour / identifier les nouveaux risques en cours de projets
Pour mitiger les risques les + courants en dév solution d’affaires
SOLUTION/PRODUIT/TECHNO
- comprendre et préciser les hypothèses
- réduire la complexité et les exceptions, et réutiliser lorsque possible
- en faire le moins possible (portée)
- prioriser les risques + importants (ex: performance, sécurité et intégration) dès le départ (budget & énergie à 100%)
- itérer, s’ouvrir au feedback, rester flexible pour ajuster besoins et processus
- stratégie d’essais utilise des données réutilisables /
- compréhension règles affaires vs données converties
ÉQUIPE & ENVIRONNEMENT
- expérience ensemble
- expérience avec technologie (expert si requis)
- environnement et outils performants et disponibles (ne nuisent pas)
- démarrer rapidement / rythme 1er livrables ; terminer planification après
- contingence pour dépendances externes
- pilote/PO représentatif et décisionnel (acceptation)
- maturité équipe & client avec approche/métho
- éviter assignation temps partiel **
- mitiger matriciel en communiquant responsabilités claires pour chacun
** leadership d’influence = objectifs + attentes indiv + standard élevés + feedback succès + responsabilisation
- Équipe + petite possible (communications), regrouper en petites équipes, offrir soutient admin
ORGANISATION
- manque d’implication de la direction / sponsor
- patrimoine applicatif important
EXEMPLE DE RÉALISATIONS:
J’ai une grande sensibilité aux risques (comme pour la résolution de problèmes). Dans ma nature de les anticiper, et d’avoir des options en cas ou ils se réaliseraient.
Les exemples les plus parlants sont connexes à la résolution de problèmes:
1. US - Maintenir en place l’équipe de soutien (2 personnes) en 2017-18 = mitigation de risque importante (beaucoup d’interventions quotidienne et absence de Fujitsu, au coeur du fonctionnement de la solution, risque très élevé de non-disponibilité et de bris de contrat)
2. SQ - Négociation pour repartir le projet = mitigation de risques importante (retrait de l’entrepôt de données, circonscrire certains fonctionnalités floue (écrans génériques et fonctions d’analyse), retrait de la conversion de données, mise à jour de l’infrastructure pour soutenir le nouveau système, ajout de livraisons incrémentales et de flexibilité sur le remplacement de fonctionnalité car aucun budget supplémentaire)
3. Desjardins - Matriciel, risque d’intégration / planification. Leadership d’influence (responsabilités, date, escalade au besoin)
4. HQ - Refus de la proposition de prendre en charge la conception (flexiblité sur autre chose), et “due diligence” et mise de côté du cadre applicatif de CGI (risque d’intégration)
5. HQ - Risque d’acceptation de la solution - Simplifier les requis du tableau de bord, critères d’acceptation, et plan de gestion de risque.
6. SQ - Partage d’une stratégie de conversion similaire avec le client pour mitiger le risque de devoir reporter l’acceptation du système si conversion problèmatique ou données non-testées
7. Général - faciliter et accélérer le déboggage par l’activation de traces aux endroits nevralgiques du système, mesurer le type de commentaire de révision reçu, révision de conception et code pour les fonctions plus importantes, adresser les fonctions les moins certaines dans les premiers incréments
8. HS - Repartir le projet sur bonnes bases en faisant le ménage sur plusieurs sujets manquant de structure (audit à 1 mois de la livraison en acceptation, a pris 2 ans de plus pour être terminé) **Identifier et retirer **plusieurs risques du projet.
9. HS/SQ - Risque financier: régler la profitabilité de la maintenance en établissant d’avance des taux horaire selon l’expertise réelle des ressources (expertise acquise en cours de projet)
Comment garder le contrôle d’un projet?
3 leviers pour maintenir une prévisibilité élevée (projet = parties mobiles en tout temps)
(1) Garder le contrôle sur l’exécution de ce qui est connu
- Gérer la portée (–>Q)
- Gestion par livrable = budget + date de fin
- avancement+RAF: TOUT inclure (PES, risques, révisions, meeting, etc..) -> coaching
- approbation et rétroaction du client (DDC?) - QUALITÉ à toutes les étapes (–>Q)
- Régler PES ouvert (impacts?)
-
Mesures/KPI utiles (selon mon expérience)
- EV (avancement réel)
- DDC (Nb/$)
- Livrables (regard et qualité des commentaires)
- Anomalies (par cas d’utilisation, durée)
(2) Garder le contrôle en gérant les risques (–>Q)
(3) Garder le contrôle en gérant les relations
- Attentes réelles des parties prenantes?
- Feedback en continue sur la performance des individus, du chef de projet, et de la qualité du système
- Prendre soin de sa capacité d’influence et seulement de la direction
NE SE FAIT PAS SEUL; équipe engagée / esprit de corp aide énormément à anticiper / signaler les “écarts” (–>Q)
Comment gérer la PORTÉE d’un projet?
SOLUTION ET PROJET (rwsp)
Le respect de la portée est avant tout un contrôle des coûts.
- Établir une base de référence (baseline) avec le client; hypothèses; inclus vs pas-inclus
- Responsabilités externes ou client de toutes livrables/activités
- Communiquer à tous les membres du projet (sensibilisation)
- Spécialement les architectes / seniors
- Écouter les besoins du client (le client ne dicte pas de solutions)
- Favoriser la réutilisation d’approche et de livrables
- Réviser les biens livrables à l’interne et obtenir approbation des biens livrables et mesurer commentaires reçus
- Mécanisme DDC clair; DDC = opportunités
-
rigidité peut être contre-productive
- Garder marge de manoeuvre $ / pas de concession trop rapides
- Garder flexibilité de remplacement de fonctionnalité (ex SQ)
- Se positionner pour l’évolution/maintenance avec une équipe “experte” (taux + élevés)
Qu’est-ce que le SUCCÈS?
Comment assurer le succès d’un PROJET?
FUSION RÉAL #10
Pour moi le succès implique les que les parties prenantes y trouvent leur compte (équité). Critères/indicateurs de succès.
LE CLIENT ET L’ORGANISATION
- Livrer de la valeur (temps/coûts/portée) avec profit n’est qu’un aspect du succès
- livraisons rapides priorisées selon valeur
- Garder le contrôle (–>Q)
- qualité de la solution et de l’exécution (–>Q)
- Mais perception > valeur
- Gérer perception et attentes des parties prenantes et leur tolérance au risque (bonne relation); attentes bien définies/comprises
- Client satisfait (–>Q)
LES INDIVIDUS
- Sont parties prenantes, et à la base du succès et doivent s’identifier au succès du projet, il en sont la mesure
- dév logiciel est complexe: embaucher individus compétents et laisser faire le travail selon les paramètres de qualité / cible (autonomie)
- engagement et communication augmente qualité et succès par capacité d’anticipation permet d’identifier les problèmes et de fouiller les attentes du client
Livraison dans $/délais/portée n’est pas nécessairement un succès.
* un manque de qualité garanti anti-succès
EXEMPLES DE RÉALISATIONS:
1. Plusieurs projets récupérés, ma cible n’était plus l’initiale en terme de calendrier ni de budget.
2. Les projets “non-récupérés” (CAL Outbound, MMI, Desjardins Web, Netcom) sont livrés selon le calendrier et dans le budgets (peuvent avoir été ajustés en cours de route avec le client) - EXEMPLE DE VALEUR BASIQUE
3. HQ (récupéré) a été livré avec 1 mois de retard (entendu avec le client) et selon le budget - EXEMPLE DE PERCEPTION BIEN GÉRÉE
4. SQ (récupéré) a été livré selon le calendrier entendu avec le client (le client a glissé beaucoup à cause de la conversion, nous avons même dû faire accepter le système sans la conversion), mais avec des pertes de 1M$
5. HS (récupéré) a été un fiasco de calendrier (+2 ans) et conséquemment de budget (-1M$)
6. L’aspect budgétaire des projets récupérés a été amélioré en maintenance grâce aux travaux d’évolution qui généraient plus que les marges prévues.
Qu’est-ce qui SATISFAIT UN CLIENT?
Réalisation démontrant que je pouvais obtenir la confiance du client?
FUSION RÉAL #9
APPROCHE ET CONCEPTS (sont aussi mes trucs):
- identifier le “vrai” client
- livrer de la qualité à chaque étape, ne pas couper pour améliorer les coûts ou le délais
- donner l’heure juste, être transparent = relation de confiance
- le rassurer, l’accompagner, qu’il sache qu’on travaille pour lui, écouter/ancitiper les besoins/attentes, rechercher relation à long terme
- apporter des solutions vs des problèmes
- apporter une **valeur ajoutée **vs contrat
- complice de la gestion de risque
- démontrer vs parler
EXEMPLES DE RÉALISATIONS:
- Desjardins ADP - Obtenir confiance de M. Latour qui n’aimait pas les consultants. L’argumentaire sur les budgets d’essais et la qualité de notre travail ont été determinants. Il m’a rappelé après la fin du projet pour savoir si j’étais disponible pour gérer un projet chez eux! Nous avons aussi pu démarrer 6 autres projets dans les années suivantes sur recommandation de ce projet ADP
- HS/SQ - Obtenir la confiance du client sur notre capacité à livrer la solution suite à la reprise. Ces 2 clients ont compris qu’on avait leur intérêt à coeur, autant que les nôtres.
- HQ - Ré-obtenir la confiance du client après le départ du chef de projet et l’escalade sur notre performance. Courriel de félicitations officiel d’HQ.
Présenté dans un format de réalisation, mais les CONCEPTS répondent directement à la question.
Quelles sont les PHASES en gestion de projet?
Démarche favorisant la gestion ordonnée d’un projet; i.e l’exécution
a. Démarrer le projet sur des bases solides
* prendre connaissance des requis, hypothèses, parties prenantes, et critères de succès (officiels et officieux)
b. Planifier de façon réaliste et complète le déroulement souhaité du projet
* Énoncés, plans, WBS, équipe
c. Encadrer (contrôler) la réalisation des tâches et maîtriser le travail accompli
* Suivi d’avancement individuel, registres, rapports d’avancement
d. Clore le projet de façon constructive
* Brainstorm + rapport = rapport de clôture -> registre expérience
* Réutilisation?
Quels sont les RÔLES en gestion de projet?
Gestionnaire de projet: tactique, gère les opérations d’un seul projet
* Expérience depuis 1998
Gestionnaire de programme: stratégique/leader/vision sur le programme constitué de plusieurs projets visant un objectif commun touchant différentes fonctions de l’entreprise. Livraison de bénéfices à travers différents projets.
* Aucune expérience officielle
Directeur de projet: tactique, dirige un ou plusieurs gestionnaires de projet (gros projet ou programme). Peut aussi gérer projets en même temps
* Peut aussi être vu comme l’utilisation de la ** technique de direction **qui va plus loin que la technique de GP/livraison de valeur (planification, organisation, contrôle) en utilisant son style de leadership en complément (se développement avec le temps mais comportement et non expérience.
- Expérience au CLD de 2007 à 2014
- propositions et projet en même temps
- direction HQ + direction maintenance applicative
- intervention auprès de client pour proposition, démarrage et escalade
Gestionnaire de portefeuille: stratégique et gouvernance, conseil à l’exécutif sur un portefeuille disparate de projets (vulgariser la valeur)
* Aucune expérience
Gestionnaire bureau de projet (PMO): stratégique, fourni information au gestionnaire de portefeuille, conseil exécutif sur amélioration processus pour soutenir objectifs organisation, vulgariser valeur projets en cours.
* Staff PMO reste technique
* Aucune expérience officielle, mais uniformisation des projets CLD (outils, suivi auprès comité de gestion)
* Rôle pourrait être intéressant pour moi, soit mise en place PMO et accompagnement
Quelles sont les tâches que J’AIMES/J’AIMES MOINS accomplir?
J’aime…
* Travailler avec un début et une fin (sentiment d’urgence + fort)
* Servir, livrer une solution, régler un problème pour un client
* Mise en place d’une équipe pour livrer cette solution, régler ce problème
* Avoir impact sur dev prof et réalisation des individus, + que techno
* Travailler dans un climat de confiance (équipe & client)
* Décisionnel : décider tactiques pour adresser problèmes SINON JLIRAIS A LA PIGE
* Communication: gérer message pour rester en mode solution et conserver confiance
* Planification et clôture (réutilisation & partage)
J’aimes MOINS…
* Projets qui n’amènent pas de changements perceptibles: difficiles à vendre à organisation et équipe
* Projet à l’encontre des valeurs d’une société
* … suivi détaillé d’une planification (avancement général, risques sont suffisants)
* * Administratif ou impératif répétitifs du contrôle (registres, rapport hebdo à rédiger). ai déjà aimé lorsque j’ai appris. aime mieux le coacher aujourd’hui et permettre à d’autre de l’apprendre
* ce qui s’éloigne de la résolution de problème et du service
Mon approche pour COACHER un PM?
Croissance d’un chef de projet
3 NIVEAUX DE MATURITE…
1) MÉTIER = livrer de la valeur (contrôle portée-temps-coût)
* apprendre à compléter des tâches
* comprendre que la qualité ne peut être compromise
* s’appuyer sur une méthodologie PMI; comprendre pourquoi les phases / livrables
* avoir une compréhension fonctionnelle de tous les domaines du PMI (autre approche), mais un **maîtrise de ses **forces (et non pas tout)
2) AJOUT MITIGATION DES RISQUES; quels sont les risques + importants et comment les mitiger?
3) OUVRIR SES HORIZONS sur le management et leadership (lectures/coaching externe)
* Intégrer processus et individus (résultats, rétention/relation)
* ne pas chercher à identifier des erreurs, mais intégrer productivité et individus.
* Organisation doit être productive pour permettre sa croissance et celle des individus
* Suivi+encadrement+coaching+communication donne de meilleurs résultats que processus uniquement
* Apprendre à identifier facteurs de motivation et niveau de suivi/coaching requis par individus
* Investir dans qualité des communications et processus décisionnel
* Être proactif dans son relationnel en se rapprochant des parties prenantes, en gérant les attentes, et en étant sensible à la culture de l’organisation
4) AUSSI…
* Se bâtir un playbook permanent - parties mibles differe tes de projet en projet
* Demander de l’aide à ses collègues…
RÉALISATIONS:
- CLD - Coacher chef de projet et ressources seniors sur meilleures pratiques et méthodologie, méthodes de management, approche à prendre avec client pour une situation x, attitude à prendre vs progression de carrière/salaire, sur responsabilités de mentorat
Pourquoi pas de PMP?
N’ai jamais pris le temps car peu important pour moi
- Ai appris avec méthodologie intégrée au PMI
- Progression 3 niveaux de maturité (valeur->risque->relations)
- Projets très structurés (ex: audit ISO)
- Ne m’a jamais empêché d’avoir projets client intéressants et demandant, ni de progresser
- PMP + valeur en début de carrière
- Ai vu des candidats PMP très théoriques qui n’avaient pas de bons réflexes/jugement en exécution. Ne pas se cacher derrière un diplôme
- Le critère PMP veut aussi dire
- une **assurance de livraison **(fait dans divers contexte pendant 20 ans)
- un accompagnement de qualité: service, satisfaction client, écoute, gestion des attentes, transparence dans l’exécution)
- l’expérience vs la connaissance
- Scrum n’est pas une garantie de livraison
- Est-ce important pour vous?
Opinion sur AGILE/SCRUM?
TERMINER AVEC CECI … L’objectif est de livrer une solution, régler un problème avec des individus motivés, de l’$ et du temps. La métho doit être choisie en fonction de la culture et l’expérience de l’organisation et de l’équipe
Alternative aux forfaits pour la gestion budgétaire, mais demande équipe avec expérience et confiance mutuelle
N’ai jamais appliqué en projet mais principes de gestion de projet s’arriment avec plusieurs valeur (4) et principes (12) de l’approche agile (peut être moins avec Scrum…)
* livrer de la valeur rapidement: incrémental
* individus et leur croissance au coeur du succès (responsabilisation)
* cycle de vie de la solution: bien conçue et s’intègre dans le patrimoine de l’organisation
* flexibilité sur l’approche, sur la portée lorsque possible (changement)
* amélioration continue
Scrum = version alourdie des principes Agile
* (+) livraison rapides / démo = feedback et ajustements + rapides
* (+) PO (décisions, responsabilités, près de l’équipe)… mais existait avec un pilote dédié
* (+) amélioration continue (sprint, feedback) … comme livraison/sous-livraison
* (+) Plus d’impact sur les petits projets que les gros (petites équipes)
- (-) Overhead / meeting / mesures vs objectif de conception logicielle qui demande un “flow” et un focus différent de la gestion (éviter changement de contexte, env calme). On vole du temps au développeurs!
- (-) focus sur projet, et non sur conception logicielle de qualité
- (-) proximité client peut induire la livraison de petits morceaux à la pièce, sans consirdération d’intégration et de perrénité. Protéger la conception logicielle.
- (-) Plupart suivent recette sans comprendre les avantages/appliquer un jugement … comme waterfall ou Macroscope par exemple
IL FAUT COMPRENDRE POURQUOI ON FAIT LES CHOSES (livrables, réunion, estimation, etc…)
* reste flexible à adapter l’approche comme on peut adapter la portée
Les projets ont besoins d’individus motivés peu importe la métho. Scrum ne peut rendre les individus motivés…
