Toutes mes réponses sur les forums
-
Messages
-
Pour cette question, il m’a fallu commenter les propositions une à une pour mieux me faire une idée…
25. You are managing a construction project using a firm fixed price (FFP) contract. The
contract is structured so that your company will be paid a fee of $85,000 to complete
the work. There was a $15,000 overhead cost that your company had to cover. It’s
now three months into the project, and your costs have just exceeded $70,000. The
project has now consumed the entire fee, and your company will now be forced to
pay for all costs on the project from this point forward. What’s the best way to
describe this situation?A. The project manager has overspent the budget.
Oui, techniquement c’est “costs just exceeded…”. Mais est-ce la meilleure façon de décrire la situation ?
Que dirait Pipa ? Pipa dirait : certes, nous avons dépensé plus que prévu, c’est un constat sur le passé et le présent. Mais c’est pas ce qui m’inquiète le plus ! A partir de maintenant, tous les coûts sont pour nous… qu’est-ce qu’on peut faire pour minimiser ces coûts, etc. C’est une préoccupation pour l’avenir, plus dans les gènes de Pipa.
B. The project is overdrawn.
Connais pas cette notion de “to overdraw”, donc c’est du bruit.
C. The project has reached the point of total assumption.
Examinons la définition du “PTA”. Pipa dirait : à partir de maintenant, tous les coûts sont pour nous…
D. The project has ceased to be a profit center for the company
J’ai deux hesitations sur celle-là, la D :
1. Ca me gêne de considérer le projet comme un “profit center”, parce que ça n’est pas nécessairement le cas, je n’ai pas d’information comme quoi il fallait à tout coup faire du profit, du coup il doit y avoir une meilleure proposition.
2. Pipa, toujours elle, est orientée “qu’est-ce que je peux faire maintenant pour améliorer la situation ou minimiser l’impact ?” Dire “on ne fera plus de profit sur ce projet” intéresse peu son sponsor. En effet, celui-ci demande à Pipa : OK, qu’est-ce que tu fais maintenant qu’on a atteint le point où tous les coûts sont pour nous ?
En me mettant à la place du rédacteur, il me semble qu’il est parti de cette définition pour rédiger sa question « princeps » :
The point of total assumption (PTA) is the point above which the seller bears all the losses of an additional cost overrun on a fixed price ‘incentive fee’ (FPIF or FPI) contract.Le rédacteur a décidé de complexifier sa question princeps en faisant trois choses :
– il parle de « fee » et de FFP, just to confuse the Russians.
– il paraphrase la définition du PTA en écrivant ceci : « The project has now consumed the entire fee, and your company will now be forced to pay for all costs on the project from this point forward.”
– il ajoute des informations en amont de sa paraphrase et elles n’apportent rien de nouveau. C’est la paraphrase du PTA qui conclut l’item.Au final, la D place Pipa dans une position de faiblesse par rapport à son sponsor, tandis que la C, du fait de sa définition, place Pipa dans une position de “je suis du côté de la solution”.
Sauvé par Pipa ?!
Oui, bien vu ! tout à fait d’accord, c’est un problème de version.
En PMBOK v6, on trouve en 9.1.3.1 le Resource management plan contenant un Recognition plan (oui, un « plan »).
Dans le PMBOK version 4, il y avait 9.1.3. Develop Human Resource Plan: Ouputs 1. Human Resource Plan, où l’on trouvait effectivement le Staffing Management Plan contenant un paragraphe (et non un plan !) recognition and rewards.
Or, ce staffing management plan est remplacé par le resource management plan dans la V6 (parce que la notion de Resources dans la V6 comprend le staffing (des personnes) et les machines, endroits, etc. toutes les ressources humaines et non humaines.
Le compilateur de ton questionaire a gardé cette question V4 dans son recueil de questions V6. Cette question devrait être éliminée d’un QCM V6 parce qu’elle est ambivalente, elle contient une réponse bonne pour la V4 et une bonne réponse pour la V6. Dommage.
C’est pour cela que je suis convaincu qu’il faut un processus de relecture attentive et sagace des questions intégrées dans un QCM d’entraînement. Travailler entre pairs pour éviter les impairs :-).En fait, Ghirlandaio, le NPV intègre déjà le calcul de l’interest rate que tu évoques, voir le tableau au-dessus.
C’est vrai, le NPV ne considère pas la payback period (durée que le sponsor devra attendre avant de dépasser le Break-Even Point et commencer à gagner de l’argent).
Pour autant, nous sommes supposés choisir le projet dont le NPV est le plus élevé, sans considérer la payback period, à moins qu’il soit statué différemment dans la question.Bonsoir, Ghirlandaio.
Dans la question que tu cites, je choisirais la réponse A.
En effet, le rédacteur joue sur le fait de prendre une partie (Act of God) pour le tout (clause de force majeure), c’est une synecdoque ☺.
Le rédacteur illustre la clause de force majeure avec un évènement « Act of God » typique. Du coup, « Act of God » serait correct, mais pas « Act of God clause ». Car « Act of God » n’est pas une clause contractuelle, c’est un événement qui déclenche la clause contractuelle qui, elle, s’appelle « clause de force majeure ».Du PMBOK 1996 à l’ECO-2019, je crois remarquer que la posture du PMI évolue. Ce ne serait pas surprenant, nous sommes tous en croissance, nos sociétés comme les parties-prenantes de nos projets, comme nous-mêmes.
Savoirs et savoir-faire
Quand j’ai passé la certification en 2000 sur le PMBOK 1996, l’instructeur nous disait : 75% des réponses sont dans le PMBOK.
Or, qu’est-ce que le PMBOK ? Un recueil de tâches et de livrables « management de projet » à produire.
Ca répondait à des questions :- Moi, PM, je commence par quoi ?
- Comment je fais ?
- Qu’est-ce que je dois savoir ?
Un peu comme s’il s’agissait d’ouvrir un restaurant. Au candidat restaurateur, qui sait faire la cuisine, il faut expliquer que mitonner des bons petits plats, c’est bien, mais ça n’est pas vraiment ce qui lui est demandé dans le cas du projet.
L’exécutive qui mise gros sur l’ouverture du restaurant s’adresse ainsi au PM :
Pour que ce restaurant ouvre, il faut que tu t’emploies à cette activité, à telle autre après celle-là, en produisant les bons documents en sachant ceci et en faisant attention à cela, etc. Et j’espère que ce restaurant sera un bon restau et qu’il dégagera des profits, et tant mieux si c’est le cas – et si ça n’est pas le cas, le principal pour toi, c’est que tu aies bien fait tout ce qu’un PM est censé faire.
Examen 2000 : voici ce que fait et ce que sait un PM responsable.
Obligation de moyens, ou quelque chose comme ça ? Savoirs et savoir-faire.Et savoir-être
Et puis, les chefs de projet ont évolué, grandi dans leur poste.
J’imagine l’ECO-2015 comme ceci : voici les situations typiques que nous rencontrons, comment est-ce qu’on s’en sort ? Avec quels principes d’action ?
Par exemple, tout ce que je dois faire, je devrais le faire en mode PDCA. Bien entendu, organiser et tenir une réunion de comité de pilotage. Autre exemple aussi, réagir à une mauvaise nouvelle.
La question à laquelle le PMI nous convoque à répondre, c’est :- Nous avons bien tout fait comme il fallait, mais des situations se produisent qui contrecarrent le progrès du projet. Comment nous PM devons-nous réagir à telles situations ?
Obligation d’application des bons principes ? Savoirs, savoir-faire et savoir-être.
Et responsabilité
Et puis, les chefs de projet ont continuer de grimper l’échelle de l’expérience et de la hiérarchie et certains sont devenus exécutives. Je me figure l’ECO-2019 comme ceci : l’ex-PM devenu exécutive s’adresse à son jeune padawan et lui dit :
- Voici à quoi je verrai que tu fais un bon PM, voici ce pour quoi je te tiens responsable.
Et le jeune padawan de répondre :
- Oups, ça fait beaucoup de responsabilités !
- Oui, envers les gens, envers les bonnes pratiques et envers le business
- OK, et qu’est-ce qui me dit que je fais bien ?
- Eh bien, réfère-toi au PMBOK pour le standard de PM, à telles écoles de pensée pour le management des gens et à telles écoles pour manager l’environnement business.
- Bon, d’accord. Et je commence par quoi ?
- Pour ça, potasse le PMBOK.
ECO-2019 : voici les défis que relève un PM responsable et comment il les relève, tous et chacun. Comme si la question était devenue :
Comment nous PM devons-nous assumer nos responsabilités ?
Obligation de résultats ? Responsabilités.Qu’en pensez-vous ?
Bonsoir, Benutzer. Oui, les réponses sont classées par ordre alphabétique, c’est une bonne pratique des QCM d’après le petit guide de rédaction de QCM de l’Université de Louvain.
Je suis d’accord que ta lecture est envisageable. En même temps, si entrer dans une étape de Storming représente un risque pour la productivité de l’équipe, s’enliser dans une étape de Forming aussi, et je manque de données dans le texte pour m’orienter vers l’un ou l’autre. A tout prendre, je penche pour la proactivité du PM (c’est au PM de donner ses consignes à l’équipe et aux nouveaux équipiers) qui accompagne son équipe dans l’étape de Forming afin qu’elle ne dure pas trop longtemps. Le PM souhaite qu’ensuite Sharon fasse son trou (Storming) et trouve rapidement sa place (Norming) pour mieux produire (Performing).
Tout à fait d’accord : il me semble que le rédacteur a zappé dans son item la notion de « Sharon a déjà maintes fois travaillé avec les membres de l’équipe projet », du coup c’est clairement par Forming que Sharon et les équipiers vont commencer à se connaître.
Nous craignons le petit nouveau qui marque immédiatement son territoire (Storming) avant d’avoir compris avec qui il travaille et qui pourrit ce faisant la productivité de l’équipe, ce que Pipa ne saurait tolérer (ni nous, d’ailleurs). Donc, Pipa le reçoit, le briefe (Team Charter, les documents du projet affichés au mur comme Charte, WBS, RACI, Resource Breakdown Structure, Macro-Planning, Performance Dashboard, etc.) et lui conseille de passer les 3 prochains jours à rencontrer les acteurs-clés de l’équipe en mode « j’écoute ce que vous avez à me dire, vous qui avez l’expérience du projet, j’observe et je me laisse observer. » (Forming).
Quant à un pro qui rejoint l’équipe avec laquelle il a déjà travaillé, je lui conseillerais quand même de commencer par Forming, car le projet a existé sans lui jusque là et il a beaucoup à apprendre de la façon dont ses co-équipiers ont entrepris le projet. Du coup, je pense qu’avec l’option « might skip a stage », le rédacteur va trop vite en besogne. Par contre, que ce Forming-là dure moins longtemps, ça, OK.
Relire le bullet point « Forming » dans le PMBOK 9.4 Develop Team, c’est éclairant.Pour ma part, je proposerais cette version optimisée :
Finally, after three months of negotiating with the resource allocation manager, a new business analyst, Sharon, has been added to your current project team. She has worked together with some of the team members in the past. Given the introduction of that new team member, which team development stage might your team fall into?
a) Forming
b) Norming
c) Performing
d) Storminga) Forming. It is common for the Tuckman team stages (Cf. PMBOK 9.4 Develop Team) to occur in order: forming, storming, norming, performing, and adjourning (reforming). Project team members have a great deal to share with Sharon about the project current status and the project management options. Since Sharon has worked with some of the project team members, they may perform the forming stage quicker together. The PM would not take the risk to promote a storming stage right away as a new member joins the team, in case it generates loss of focus or unnecessary frustrations.
Qu’en dites-vous ?
Merci, Benutzer.
Tout à fait d’accord.
Voir ici pour la correspondance ECO-2015 et PMBOK v6, le 3° outil de l’article.Excellent !
Est-ce que je pourrais ajouter un principe qui élimine d- (et confirme donc que c- est la bonne réponse) ? C’est celui de l’universalité : si je choisis une réponse, elle devrait être généralisable à la Terre entière dans la situation donnée.Or, justement, même si la modification a été réalisée, on peut essayer de la vendre au client, c’est un scénario à ne pas exclure. Le PMI ne prendrait pas la responsabilité de recommander le « fait accompli » aux 500.000 chefs de projet de l’Univers…
Effectivement, ayant baigné dans l’industrie IT au début de ma carrière, j’ai moi aussi été étonné. En même temps, à la relecture, je trouve deux genres d’éléments qui penchent effectivement pour la réponse b-.
En premier, la question-même : what should be your main concern from this incident?
En soi, la réponse d- n’est certes pas une petite inquiétude, mais pas écrasante : nous sommes en période de test, aussi les bugs secondaires seront détectés, puisque c’est le but de la manoeuvre.
Du coup, n’y aurait-il pas quelque chose dont je devrais être plus inquiet encore ?
Justement, en second, il y a tous ces petits mots qui montrent que quelque chose cloche sérieusement dans la situation :
You are a PM of a software project which is in a critical phase of testing and bug fixing. An enthusiastic test engineer working in the project tells you that he found a major bug the previous night during testing. He assures that there is nothing to worry about as he has ‘patched’ the code and it is working fine now. What should be your main concern from this incident?
L’ingénieur de test identifie un bug majeur en pleine nuit, patche le code en direct et dit : TVB ? Pas normal, tout ça.
Alors, effectivement, ma principale préoccupation est que je pourrais bien faire face à un développement sous-marin hors contrôle, réalisé au prétexte d’un bug majeur, avec potentiellement de nombreux impacts sur de nombreux documents qu’il faudrait mettre à jour. C’est la réponse b- It can be a case of scope creep and all prior documents need to be changed.
Je note que la question n’est pas : que devrais-je faire face à cette situation ?
Auquel cas, je répondrais : puisque nous sommes en phase de test et que les éventuels dysfonctionnements du patch seront mis à évidence par les tests, je laisse faire les testeurs ; par contre, je m’assure que le bug soi-disant majeur est bien un bug, que la solution apportée par mon génial testeur est bien dans les clous du contenu prévu, que tout est bien documenté. Donc, qu’il ne s’agit pas d’un développement pirate.
A la réflexion, il y a dans le texte de la question beaucoup d’invraisemblances qui me convainquent que nous ne sommes pas dans le déroulement normal d’une phase de test. Convaincu ?
Solution
b- It can be a case of scope creep and all prior documents need to be changed.
En tous cas, courage et confiance, ne lâchons rien !
Bon réflexe, Ghirlandaio : comment cela peut-il être la réponse PMI valable la plupart du temps pour la plupart des projets ? Effectivement, en l’absence de contexte (ces phrases qui détaillent la situation dans les longues questions… situationnelles), il faut, pour bien répondre à la question posée, se reporter à la situation par défaut du PM vu par le PMI : celle de Pipa.
Du coup, « b- Integrator » est bel et bien le meilleur choix.
Oui, mais alors, que faire de la notion d’intégrateur, ou du type particulier de projet d’intégration ?
C’est vrai que « intégrateur » fait partie du vocabulaire du management de projets informatiques en communauté francophone. Justement, parce qu’il est spécifique, ce sens n’est pas celui qu’il faut retenir dans cette question soumise à tout PM, qu’il soit francophone ou pas, dans l’industrie informatique ou non.En l’absence de contexte, c’est Pipa qu’il faut regarder. Or, Pipa, à la tête d’un gros projet international, est précisément en situation d’intégrer toutes les parties prenantes dans un contexte de forte transversalité, d’où le fait que la plupart de ses actes ont un sens pour des parties prenantes, et qu’il s’agisse donc de « communication ».
Recherche de confirmation
Examinons les autres réponses possibles pour les éliminer, si nous pouvons.
Pourquoi pas a- Servant Leader ?
Parce que, si le PMBOK évoque plusieurs styles de leadership dans 3.4.5.1 Leadership Styles, il n’indique pas quel devrait être celui à préférer toutes choses égales par ailleurs. Ce qui importe, c’est d’adapter son style aux circonstances (ce que Blanchard dit être l’apanage de 20% des manageurs, ou moins).
Pourquoi pas c- Single Point of Contact ?
Parce qu’à elle seule, la notion de SPOC n’implique pas une communication à tout moment, comme le suppose la question.
Pourquoi pas d- Customer Management ?
Certes, le client et ses représentants sont, qu’ils soient internes ou externes à l’organisation, des parties prenantes importantes et ils requièrent qu’on planifie la communication avec eux. En même temps, tous les projets, loin de là, n’imposent pas que la quasi totalité des interactions du PM soit dédiée au client et à ses représentants. Il y a aussi les autres parties prenantes, personnes ou groupes de personnes dedans et dehors l’organisation de Pipa, intéressées de près ou de loin, positivement ou négativement, au projet ou au produit du projet.
Ainsi, par élimination, c’est bien la b- Integrator, qui surnage !
Ouf ! Courage, confiance, ne lâchons rien !
En fait, pourquoi se poser cette question ? Mon objectif, c’est de réunir de l’énergie pour ce qui a du sens pour chacun. Que chacun réunisse l’énergie pour ce qui a du sens pour lui.elle.
Comment y parvenir ? Ce que je veux proposer, c’est une personnalisation de la formation au management de projet, un compagnonnage entre responsables sans autorité hiérarchique.
Ce serait comme partir ensemble en voyage, chacun recevrait le juste nécessaire dans son sac à dos (léger, donc) pour rallier la prochaine étape, le prochain cycle. Et chacun partagerait le contenu de son sac avec les autres selon leurs besoins. Les victuailles, plus on partage moins il nous en reste, et on finit par épuiser le stock. Dans notre cas, ce sera le contraire : ce qui a été partagé augmentera ce qui est partageable à l’avenir, plus on partage, plus le stock augmente !
