Archive d’étiquettes pour : Gestion de projet

Go ? No go ? Est-ce la bonne question à se poser avant de lancer un projet ?

Interrogé dernièrement dans le cadre de la mise à jour d’un schéma directeur informatique, il nous a été demandé d’arbitrer entre différents projets informatique pour décider de les lancer ou non. Le « Go ? No go ? » est peut-être la question la plus fréquente et la plus importante qu’un responsable de projet (avec l’aide de ses collègues) va se poser avant de prendre en charge un projet, qu’il soit en approche projet « prédictive » ou agile. Est-ce la bonne formulation pour décider ou non de lancer un projet et quelles sont les autres variantes.

De nombreuses approches de gestion de portefeuille de projets estiment que le « Go ? No go ? » est un processus de prise de décision trop binaire, ce que l’on peut donc considérer comme une erreur. Quelques exemples de décision d’y aller pour un projet :

  • Nous avons réalisé une bonne année, nous avons le budget, c’est le moment de nous lancer dans ce nouveau projet.
  • Parmi la concurrence, il va y avoir une nouvelle offre plus performante que la notre. Et si on avançait notre lancement de projet de quelques mois ? Cela nous permettrait d’aborder cette concurrence dans de bonnes conditions.
  • Avec de la marge supplémentaire ajoutée au planning, j’accepte d’embarquer dans mon projet les futures demandes du marketing non exprimées à ce jour, et je lance mon projet en l’état.
  • Et si on découpait le projet en s’arrêtant à mi-parcours pour faire un petit état des lieux sur les nouveaux besoins, avant d’entamer la deuxième phase et limiter les risques ? On lance de suite le projet et on laisse ainsi les idées se mettre en place et se préciser et on continue après avec de bonnes visibilités sur les fonctionnalités à offrir et à ajouter à notre projet.
  • Les conditions du projet sont proches de mes limites en gestion de projet et des connaissances techniques de l’équipe. Je décide de partir avec un consultant plus expérimenté, qui en plus connaît bien cette nouvelle technologie. Je l’engage contractuellement jusqu’à la fin estimée de mon projet.

Du point de vue gestion de projet, le « Go ? No go ? » est souvent une erreur, voire un danger. En effet, si au vue des conditions internes et externes au projet, un décideur ou un chef de projet choisit la réponse « Go », il part et lance son projet avec le sentiment que le déroulement pourra se réaliser dans son intégralité suivant le plan initial. En clair, il se met des œillères, et aura du mal à changer de plan de projet si les conditions sont différentes des prévisions.

Les nouvelles approches de gestion de projet, et en particulier l’agilité, proposent donc une variante : « Start / Continue ». L’expérience sur les nombreux projets nous a fait comprendre à quel point il est important de toujours rester méfiant vis-à-vis des prévisions initiales d’un projet et d’avoir un plan B, voir C, D…

Avant le lancement, le chef de projet doit analyser tous ses paramètres projet et conclue que le lancement du projet est possible. La prochaine réflexion se fera une fois le projet lancé, à savoir si celui-ci peut se poursuivre jusqu’à destination suivant le plan projet initial, ou s’il y a nécessité de se dérouter, c’est à dire, modifier le périmètre, les délais, le budget, l’équipe… Ainsi, le chef de projet n’arrête pas le processus de prise de décision une fois le projet lancé. Il sait que les conditions lui permettent dans un premier temps de démarrer son projet, et il affinera l’analyse une fois lancé afin de répondre à la seconde interrogation : « Continue ? ».

Conclusion

Ces stratégies de conduite de projet, basées ou non sur les approches agiles, demandent un peu d’expérience (avant de se lancer dans des prises de décisions complexes), de jugement et bien sûr nécessite de la préparation en amont. Elles n’excusent en rien les mauvaises prises de décisions ou les comportements du genre « On va voir ce que ça donne une fois le projet lancé ou les premières livraisons effectuées ». Un projet ce n’est pas binaire, il faut savoir ajuster son pilotage et ses décisions tout le long de son déroulement, et jusqu’à la fin, pour bien le finaliser.

Vous avez aimé cet article ? Alors partagez-le avec vos relations en cliquant sur les boutons ci-dessous :

 
/0 Commentaires/par

Méthode Agile et Gilets Jaunes – Emmanuel Macron, première victime à déplorer de l’agilité

,

Méthode Agile, agilité en entreprise, agilité en gouvernance… ce mode de management de projets est à la mode depuis maintenant quelques années. Ce management « agile » est inspiré d’une approche dans le développement d’applications informatiques. Cette approche a été conçue pour remédier aux écarts constatés entre les attentes des utilisateurs et les outils informatiques livrés suite aux développements. Pour cela, on applique un manifeste qui conseille l’adaptation aux changements, plutôt que le suivi d’un plan, on livre fréquemment le logiciel informatique fonctionnalité par fonctionnalité, on privilégie le dialogue en face à face via des points quotidiens.

Cette approche projet et de management d’équipe a eu un tel succès dans l’informatique qu’elle a rapidement été appliquée au niveau des autres entités de l’entreprise, RH, marketing, production.

Le succès a été tel que l’approche agile est arrivée à l’Elysée et le terme est fréquemment employé par le président français lui-même, Emmanuel Macron.

Mais désormais, Emmanuel Macron doit rire jaune avec l’approche agile et les gilets (il fallait bien que je place quelque part ce jeu de mots un peu tordu … bon, ça c’est fait 😉 ).

En effet, avec la crise des « gilets jaunes », on constate une nouvelle fois, l’importance de la bonne prise en compte des parties prenantes, de la conduite du changement, de la gestion des risques… dans tout projet, qu’il soit agile ou non. On ne peut que constater en France, que l’approche agile du nouveau gouvernement et la rapidité de la mise en place des nouvelles réformes n’ont pas obtenu l’adhésion de toutes les parties prenantes, c’est à dire, de tous les Français.

Moralité, au 21e siècle, et malgré l’approche agile, on peut aller droit à l’échec d’un projet, qu’il soit informatique, d’un autre secteur de l’entreprise ou politique.

Donc, un conseil à notre président et aux managers, oui à l’agilité, mais pas au détriment des parties prenantes de vos projets, sinon, vous allez vous prendre une veste, qu’elle soit jaune ou pas ! Avant de vous lancer un peu trop vite dans vos « sprints » projets, analysez bien les impacts sur les parties prenantes, essayer de répondre à leurs attentes et prenez en compte l’ensemble des acteurs impliqués ou pouvant influencer votre projet. Ce n’est pas simple, mais c’est tout le charme du management et des facteurs humains !

Vous avez aimé cet article ? Alors partagez-le avec vos relations en cliquant sur les boutons ci-dessous :

 
/2 Commentaires/par

Gestion de projet, quand il y a un doute, c’est qu’il n’y a pas de doute !

Cette citation, « quand il y a un doute, c’est qu’il n’y a pas de doute !« , entendue lors de mes débuts de jeune pilote de planeur, s’adapte parfaitement à la gestion de projet (informatique ou non). En effet, quand on est jeune pilote, on apprend à ne pas s’engager dans une situation que l’on ne sera pas gérer, et qui pourrait nous amener au drame.

Planeur en vol

En gestion de projet, notre vie humaine est rarement mise en jeux, mais les dégâts d’un projet mal embarqué peuvent être importants. C’est pourquoi, si vous ressentez un doute, c’est qu’il n’y a pas de doute ! Il faut dans ces moments, prendre du recul, lever le nez du guidon, et analyser la situation. Comment ?

Revenez à vos domaines de connaissances de base de la gestion de projet, et réalisez votre « circuit visuel » de chef de projet pour reprendre le contrôle :

  • Suis-je toujours en train de réaliser le travail attendu, et seulement ce travail requis, pour mener à bien ce projet ?
  • La gestion des délais est-elle toujours sous contrôle ?
  • La gestion du budget est-elle maîtrisée ?
  • Ai-je toujours des indicateurs me permettant de savoir si je réponds bien aux besoins et attentes pour lesquels le projet a été entrepris ?
  • Les intervenants sur le projet sont-ils bien identifiés, disponibles, informés, organisés et suivis pour réaliser les activités du projet ?
  • La communication autour du projet est-elle bien planifiée, réalisée et sous contrôle ?
  • L‘identification des risques, leurs qualifications et les actions associées sont-elles bien réalisées, et ceci, à intervalle de temps régulier ?
  • Les biens et services nécessaires au projet sont-ils planifiés, suivis et contrôlés ?
  • Les différentes personnes concernées, impactées par le projet et pouvant influencer sur le déroulement du projet sont-elles identifiées, suivi et accompagnées ?

Si je ne prends pas en compte mon doute et que je ne réalise pas assez vite cette révision de mes paramètres de mon projet, que va-t-il se passer ?

Petit à petit, dans votre progression de votre projet, sournoisement, un déphasage va s’installer entre ce que vous voyez sur le déroulement de votre projet (délai, objectifs, budget) et ce que vous ressentez.

Une situation d’inconfort va grandir dans votre tête. Il va vous falloir faire un effort de raisonnement pour lire vos indicateurs de la situation de votre projet et pour décider des actions à mener et à ordonner à votre équipe. Vous allez devenir un chef de projet qui manage mécaniquement, à partir de ce qui a été planifié. Et à un moment, vous allez ne plus contrôler votre projet, et votre comportement et votre management va devenir brutal. Vous allez peut-être bien vous sortir de cette situation, mais bien souvent, avec des dommages collatéraux !

Bref, évitez de rentrer dans cette zone d’inconfort et de non-contrôle du projet. Anticipez !

Et sachez écouter vos ressentis… et s’il y a un doute, c’est qu’il n’y a pas de doute !

 

 
/0 Commentaires/par

Un secret confié par les vieux chefs de projets aux jeunes Scrum Master et Product Owner !

Je suis parfois un peu surpris par le manque de respect de certains jeunes Scrum Master face aux anciens chefs de projets et à leurs « anciennes méthodes » dites prédictives. Pourtant, ces « vieux chefs de projets » avec leurs anciennes méthodes de conduite de projets ont parfois à leurs actifs de belles réussites.

Bien souvent, il est a noter certaines différences entre les chefs de projets peu et fortement expérimentés, comme la conscience des risques sur les projets qui est proportionnelle à l’expérience.

Est-ce là l’effet Dunning-Kruger qui se manifeste et qui démontre que les personnes les moins compétentes surestiment leurs compétences, alors que les plus compétents ont tendance à les sous-estimer.

Chez un bon chef de projet, l’expérience est primordiale pour forger nos compétences, remplaçons donc le terme « incompétence » par « peu expérimenté » et nous obtenons les symptômes suivants :

  • Un chef de projet ou scrum master peu expérimenté tend à surestimer son niveau de compétence,
  • Un chef de projet ou scrum master peu expérimenté ne parvient pas à reconnaître la compétence dans ceux qui la possèdent véritablement,
  • Un chef de projet ou scrum master peu expérimenté ne parvient pas à se rendre compte de son degré d’incompétence et de sa faible conscience des risques,

L’expérience acquise par ces chefs de projet ou scrum masters, synonyme de nouvelles compétences, leur permet de reconnaître et d’accepter leurs lacunes antérieures.

Si vous êtes un chef de projet ou scrum master peu expérimenté, gravez la première assertion dans vos neurones. Et dites-vous bien que ces chefs de projet « old school » plus expérimentés qui vous entourent ne vous racontent pas que des bêtises sur la conduite de projets !

Cet effet est particulièrement gênant sur des projets à risques, et il se vérifie assez facilement dans les projets à forts enjeux gérés en approche Agile.

Les chefs de projet ou scrum masters les moins compétents surestiment leurs compétences, alors que les plus compétents ont tendance à les sous-estimer.

Attention cependant à ne pas mal interpréter ces lignes pour les plus expérimentés, d’autres facteurs vont conditionner la capacité à bien gérer un projet : le niveau de formation, l’éducation, les croyances, la culture, les compétences interpersonnelles… Autant de facteurs qui vont influer sur vos raisonnements et votre attitude dans la gestion d’un projet.

Sur ce, bons projets aux uns et aux autres !

 
/0 Commentaires/par

Le Scrum Master m’a tuer… MSI.nc enquête sur la disparition du chef de projet !

Le chef de projet est-il réellement mort ?

Mais non, je vais rassurer de suite certains, nos jeunes Scrum Master et Product Owner n’ont jamais eu autant besoin de ce bon vieux chef de projet expérimenté ! Les méthodes agiles ne vont pas tuer les chefs de projets, responsables de projets ou le PMO (Project Management Office – « bureau de gestion de projets »). Par contre, ces métiers sont en évolutions constantes et se professionnalisent. Et c’est tant mieux ! Pour résumer, le chef de projet, c’est un peu comme un roi ! Le chef de projet est mort, vive le chef de projet ! Attention tout de même, l’histoire des rois ne termine pas forcément très bien 😕

Quelles évolutions pour la gestion de projet ?

Petit à petit, le développement de la gestion par projet dans les entreprises a fait prendre conscience de la nécessité de mieux gérer cette approche à la fois au niveau stratégique, organisationnel et humain. Nous assistons a une prise de conscience de la nécessité de créer une cellule ou un service de management des projets. Cela devient de plus en plus un domaine stratégique pour l’entreprise. Et nous assistons à la création de PMO, ou cellule de gestion des projets au sein de plus en plus d’entreprise et d’organisation. Cette création entraîne également la pleine reconnaissance du rôle de chef de projet (ou responsable de projet), au lieu d’ajouter des tâches de gestion de projets à des employés déjà occupés sur d’autres activités.

Quelles évolutions majeures pour le responsable de projet ?

A moins que vous ayez passé les deux dernières années sur l’île Surprise (à vous de chercher où ça se trouve 😆 ), vous savez que désormais le responsable de projet doit être agile … Très bien, mais encore ? Aujourd’hui, les projets doivent être plus flexibles, plus collaboratifs, plus itératifs. Un chef de projet doit désormais s’adapter quasiment en temps réel aux demandes de leurs clients ou commanditaires. Mais dois-je oublier ce que j’ai appris sur la gestion de projet avant l’arrivée de Scrum et consort ?

Non, rassurez-vous avant de repartir immédiatement sur votre atoll (tiens, tiens, je viens de vous donner un indice pour l’île Surprise), le chef de projet doit plus que jamais, gérer les coûts, les approvisionnements, les risques, les parties prenantes, les ressources humaines, la qualité, les livrables, les délais des projets. Et vos connaissances et expériences en matière de conduite de projet restent indispensables et valent de l’or pour les jeunes Scrum Master et Product Owner ! Et l’agile ne va pas vous tuer, mais vous conforter dans votre expérience et savoir faire si vous savez vous adapter à la modification du processus projet. L’Agilité, on en fait tout un tapage médiatique, pour permettre à certains consultants de se justifier, de bien facturer, pour se payer leur prochain séjour sur l’atoll Surprise, mais c’est juste une évolution naturelle des processus de conduite de projet vers une approche plus flexible et plus itérative.

Le Scrum Master m'a tuer

Le Scrum Master m’a tuer – Pour les plus jeunes, voir https://fr.wikipedia.org/wiki/Omar_m’a_tuer

Le Scrum Master, le Product Owner et le chef de projet peuvent-ils cohabiter ensemble sur un même projet ?

Sur des petits projets, pas nécessairement, par contre, sur des projets importants, chacun va gérer sa partie. Le chef de projet est là pour gérer les ressources humaines, le budget, la gestion des parties prenantes, les risques, les approvisionnements… Le Scrum Master et le Product Owner vont quant à eux gérer la réalisation en approche agile en gérant les priorités, la coordination des équipes, le respect des délais à court terme, la qualité des livrables par Sprint, l’intégration en continu…

Mon processus projet doit-il être forcement agile ?

Tout d’abord, il n’y a pas de débat sur un point, l’Agilité est une approche qui va perdurer, même si elle peut prendre un nouveau nom d’ici quelques années pour raison marketing ! Cette approche permet d’augmenter les chances de réussite de beaucoup de projets, particulièrement dans le domaine du développement informatique. Si aujourd’hui, je dois me lancer dans un projet de développement, je n’hésite pas pour adopter cette approche dans mon projet. Et pourtant, sur d’autres types de projets, plus innovants, plus impactant pour l’organisation, plus stratégique, plus long pour leur réalisation, nécessitant beaucoup d’intervenants, je commencerais par une approche plus classique avant d’adopter ou non l’approche agile.

Peut-on imager l’approche agile pour développer un projet d’habitat sur Surprise ? Non, une bonne gestion de projet correctement initialisée avec la prise en compte des parties prenantes (en l’occurrence, pour Surprise, il s’agit des tortues, des frégates, des fous, des raies…) et une gestion du risque vous indiqueront très rapidement qu’il ne faut surtout pas lancer un tel projet, même en approche agile …

Pour terminer, où se trouve l’atoll « de la Surprise » ?

L’atoll de la Surprise est une île corallienne au nord-ouest de la Nouvelle-Calédonie. À ce titre, il est depuis 2008 inscrit avec les lagons de Nouvelle-Calédonie au patrimoine mondial de l’UNESCO.

Vous avez aimé cet article ? Alors partagez-le avec vos relations en cliquant sur les boutons ci-dessous :
[sgmb id= »1″]

 
/0 Commentaires/par