Le chef de projet : un super capitaine sous pression ! #Chefdeprojet #Gestionprojet #unroleimportant #unrolecentral

Une image qui m’avait été soufflé par un de mes stagiaires en gestion de projet : le chef de projet peut être comparé à un capitaine de navire.

Aujourd’hui, c’est une de mes images préférées pour parler du chef de projet.

Faisons un peu travailler notre imagination : (entre parenthèse ce qui peut être démontré.

Le capitaine (chef de projet) doit mener son bateau de Brest à New-York (l’objectif, non SMART, je vous l’accorde) dans un délais de 3 semaines (délais).

Avant de démarrer, il va :

• préparer la route à suivre (le planning),
• choisir son équipage (son équipe),
• prévoir les vivres pour la traverser (les moyens techniques),
• regarder la météo pour voir s’il y aura des tempêtes ou autres (les risques),
• Adapter sa route en fonction de la météo (plan de prévention des risques et mise à jour du planning).

Une fois toutes ses étapes réalisées, il va pouvoir se lancer dans l’aventure de la traversée ! C’est parti !

Bien sûr, avant de partir, il aura pris le soin de distribuer à l’équipage les différents rôles, et d’organiser un point pour présenter l’équipage et le plan de route ! (En gestion de projet on n’oublie pas de réaliser également ces actions !).

Voilà, on est parti, et comme pour un projet, le capitaine devra faire face à quelques difficultés qu’il n’avait pas prévu !

Tiens le petit matelot, il a le mal de mer, il ne peut donc pas tenir son poste ! Il doit du coup adapter la répartition des rôles !

Après vérification de la météo, il voir qu’une tempête vient droit sur eux ! Quelle décision prendre ? contourner la tempête et perdre quelques jours, continuer droit sur la tempête et tenter de la passer pour tenir le délai ? mais avec un certains nombres de risques supplémentaires. A lui de prendre la meilleure décision, pas facile, il est seul face à la décision, et il subit la pression de l’armateur (le directeur de projet) qui veut satisfaire le client qui attend sa livraison  : doit-il mettre son équipage en danger ou risquer de ne pas satisfaire l’armateur ?

Il prend la décision de contourner la tempête car moins dangereux pour son équipage. Mais voilà, il va passer des heures par radio à se justifier auprès de l’armateur qui ne décolère pas, il aura 3 jours de retard, ce n’est pas concevable, mesure-t-il l’argent perdu par la compagnie ?

Du coup, vu qu’il est sous pression, il va mettre la pression sur son équipage, on contourne la tempête mais bon faut qu’on tienne le délais alors on diminue les temps de repos. On se donne à fond.

Voilà, on est enfin arriver à New-York avec un jour de retard, et là que constate-t-on ?

1. Le client n’est pas content, la livraison n’a pas eu lieu en temps et en heure. Surtout que l’armateur ne l’a pas prévenu du potentiel retard, il attendait sa livraison sans aucune information (merci l’effet tunnel !).
2. L’armateur n’est pas content, le capitaine n’a pas répondu à son objectif de délai.
3. L’équipage n’est pas content : le capitaine leur a mis la pression !

Et le capitaine dans tout cela ? ben, il a fait de son mieux, il devait satisfaire : le client, l’armateur et l’équipage. Il était seul face aux décisions avec une triple pression.

Voilà un peu la difficile vie des chefs de projet, seul face aux décisions (ou très peu épaulé), mais devant rendre des comptes aux clients (ils sont en première ligne), à leur hiérarchie (qui souvent oublie les aléas projets, pourtant quand ils étaient chef de projet….), et l’équipe.

Aujourd’hui, autour de moi, je me rends compte qu’il y a de plus en plus de chef de projet à bout, qui n’en peuvent plus ! On parle beaucoup de Burnout, mais c’est un mal de plus en plus courant pour les chefs de projet.

Il aurait pu prendre la décision de passer la tempête, il aurait satisfait l’armateur, et le client mais là, cela aurait été  une partie de l’équipage qui aurait craqué !

Et oui, il est vraiment dans une position très inconfortable, les méthodes agiles permettent un peu de contourner ce mal être mais il est trop présent aujourd’hui dans de nombreuses sociétés.

Il faut que cela change, il faut qu’il y ai une prise de conscience générale que l’on ne peut pas continuer comme cela à mettre la pression soit sur le chef de projet (manager de proximité), soit sur l’équipe !

Bien sûr il y aura toujours des personnes qui se diront, mais non, ce n’est pas vrai ! Elle exagère ! (si, si, j’ai déjà les oreilles qui sifflent !).

Mais pourtant, de ce que je vois en formation, de ce que j’entends c’est devenu courant le burnout des chefs de projet. En 2016, je n’ai pas fait une formation pour des chefs de projet sans en avoir un ou plusieurs à la limite du burnout ! Il venait souvent là pour essayer de trouver des clés pour s’en sortir !

Et là, depuis 3 semaines, deux personnes qui me parlent aussi de ce burnout du chef de projet ! cela m’a fortement interpellé ! Car c’est pour cela (entre autre !) que j’ai quitté le monde du salariat, je n’en pouvais plus de cette pression continuelle ! Mais finalement, je n’étais pas la seule, ils sont nombreux mes collègues dans le même cas !

Une personne, ancienne chef de projet, qui s’est lancé dans l’entrepreneuriat et qui me parlait de ses anciens collègues : « ils sont nombreux en burnout. ».

Un de mes étudiants qui me dit : « mon maitre d’apprentissage, il est absent car en burnout. ».

Vraiment, il est urgent que cela change ! il est urgent que tout le monde comprenne l’importance de remettre l’humain dans les relations professionnelles ! Mais aussi qu’on arrête de taper sur le manager / chef de projet qui a pris sous la pression la décision de passer dans la tempête ! Il était devant un dilemme important : satisfaire son équipe ou satisfaire son manager ? La pression était importante, il a pris une décision, cette décision n’est pas la sienne, c’est celle de la pression. C’est la décision qu’on lui demande de prendre car souvent s’il veut conserver son poste et son travail il n’a pas le choix ! Franchement, il y a des moments où j’ai pris des décisions dans lesquels je ne croyais absolument pas, mais je n’avais pas le choix. C’est une décision que j’appellerais la décision de la pression mais pas du cœur !

Aujourd’hui, il est important de remettre les décisions du cœur dans l’entreprise pour le bien-être de tout le monde ! De l’armateur au matelot ! Tout le monde est important, tout le monde à sa place, mais surtout tout le monde est dans le même bateau ! Alors arrêtons de faire des trous dans la coque !

Soyons uni de l’armateur au matelot pour redonner du sens à nos projets  ! à notre travail !

Aujourd’hui, c’est un sujet qui me tient à cœur, c’est pourquoi je vous prépare une offre pour aider le chef de projet / manager de proximité à trouver sa place, à s’affirmer mais surtout à éviter le burnout pour lui ou pour les membres de son équipe !

 

Comment parler à son équipe ? #Chefdeprojet #Gestionprojet #parleràvotreequipe #utiliserlebonvocabulaire

Lorsque vous parlez à votre équipe, il est vraiment important d’utiliser le bon vocabulaire !

Et oui !

Lors de votre réunion d’équipe, si vous dites à votre équipe la phrase suivante « Alors, cette semaine, mon projet a bien avancé ! ».

 

A votre avis : comment va le prendre votre équipe ? Qu’est-ce qui va se passer dans leur tête ?

 

Là, vous êtes bon pour ramer un petit moment pour les remotiver ! Car enfin de compte, vous ne reconnaissez pas leur travail, leur participation à votre projet !

 

A la place, testez plutôt : « Alors cette semaine, notre projet a bien avancé ! »

Ok, la phrase n’est pas la meilleure mais déjà là vous allez gagner un point ! Vous ne vous êtes pas approprié le projet, vous reconnaissez leur implication ! Vous ne les démotiverez pas !

Vous vous demandez quelle est la phrase idéale ? J’ai envie de vous dire elle n’existe pas, car tout dépendra de votre équipe, des profils..

Mais essayez de leur dire :

« Cette semaine, je suis content du travail de l’équipe, notre projet a bien avancé ! ».

Là, vous marquez un 2ème point car vous les félicitez ! Oui, vous pensez à les valoriser, à donner de l’importance à leur travail, à leur effort ! Et là, vous les motivez pour la prochaine semaine ! Dans leur tête, il y a un petit « Yes ! Le chef reconnait le boulot fait ! Il n’a pas été fait pour rien ! »

 

Il est vraiment important dans votre formulation que vous pensiez à les féliciter, à souligner les efforts de chacun.

Si après une mise en production un peu tendu vous dites « Bon, on a eu des difficultés, mais c’est en production, je suis satisfait ! ». Vous pensez que vos collaborateurs, ils vont apprécié ?

Là, je pense que vous avez la réponse. (Oui, c’est bien non !).

Souvenez-vous de ce que je viens de vous expliquer ! Alors comment vous formulerez votre phrase après une mise en production un peu tendu ?

Une petite suggestion « Je tenais vraiment à vous remercier des efforts que vous avez fourni, car même si nous avons rencontré des difficultés lors de la mise en production grâce à l’implication de tous, nous avons réussi. ».  Vous pouvez même ajouté : « Vous pouvez être fière  de vous ! »  que je préfère à « Je suis fière de vous ! », mais cela c’est mon ressenti personnel !

Alors pour résumer :

1. C’est le projet de l’équipe et non pas votre projet
2. Penser à remercier l’équipe des efforts fournis !

Choisir son outil de gestion de projet #Chefdeprojet #Gestionprojet #outil #planification

Une question qui revient régulièrement en formation, quel outil de gestion de projet utiliser ?

Je vous ai répondu partiellement l’autre jour sur mon article sur Excel (ici), et actuellement je travaille à vous proposer très prochainement un livre blanc sur le sujet.

On distingue 5 catégories d’outil  :

• Excel,
• Les outils gratuit en ligne,
• Les outils gratuit à installer sur votre PC,
• Les outils payant à installer sur votre pc,
• Les outils payent en ligne.

Ils ont tous des avantages et des inconvénients, et ils ne s’adressent pas au même public !

Le choix dépendra :

1. De la taille de votre projet ?
2. De la taille de votre équipe ?
3. Faites-vous une gestion de budget ?
4. Disposez-vous d’un budget pour l’acquisition d’un logiciel ?
5. Avez-vous l’autorisation d’installer un logiciel sur votre PC ?
6. Vos données sont-elles confidentielles ?
7. Devez-vous gérer du multi-projet ?

 

Vos réponses vont conditionner le choix de l’outil !

En gestion de projet, nous disposons de beaucoup d’outils ! J’avais un jour trouvé une liste de plus de 100 outils ! (du coup, j’ai abandonné mon projet de tous vous les tester !!) Le choix vu le nombre d’outils n’est pas toujours facile !

Quelques pistes :

1. Pour des projets de moins de 50 jours, Excel peut suffire !
2. Si vous tourner entre 50  et 400 /  500 jours, avec une équipe modeste, les outils gratuits, c’est la solution pour vous !
3. Si votre projet est important (plus de 500 jours), qu’il faut gérer une ou plusieurs équipes. Là, il vous faut aller vers des outils payant !

Et oui, dans certains cas, je préconise vraiment les outils payants ! Aujourd’hui, il y a vraiment de très bon outil sur le marché  !

Sur les outils gratuits, même les plus complets, il manque des fonctionnalités ! Je me souviens de la 1ère formation planification avec MS*Project pour réaliser les exercices que j’ai dispensé. Un des stagiaires m’a demandé l’autorisation d’utiliser un logiciel gratuit car dans sa société pas de possibilité d’achat de MS*Project. Pas de problème pour moi, l’important est qu’il fasse les exercices pour apprendre à planifier ! A la moitié de la formation, il me dit : « Pour la suite je repasse sur Project car là, ce n’est plus réalisable avec l’outil gratuit ! ». Juste pour vous dire, que pour des fonctionnalités poussées, il n’y a pratiquement que les outils payants, donc il est vraiment important de vous poser les bonnes questions pour faire votre choix ! (Je prévois un petit arbre décisionnel dans mon livre blanc !!! Il arrive, soyez patient !).

Les informaticiens des nuls ? #Notedhumour #chefdeprojet #Gestionprojet #Analyse

Une petite note d’humour aujourd’hui !

Non, franchement ! On est nul ! On livre régulièrement des applications qui ne répondent pas aux besoins du client !

Et là, ce soir, je vois une personne qui s’improvise analyste !!! Ben, oui, il se propose de réaliser sur un coin de table : l’analyse pour une demande d’une copine pour un logiciel ! C’est certain, c’est la bonne méthode ! Purée, la copine, elle va avoir un super logiciel, qui répondra super bien à ses besoins !

Non, franchement, nous avec nos méthodes ! On peut aller se recoucher ! Mais oui, c’est cela, la bonne méthode d’analyse ben c’est sur un coin de table !

Fait vraiment qu’on revoit nos pratiques ! Nous n’avons rien compris, vu que nous livrons souvent des logiciels ne répondant à pas à 100% aux besoins !

On revoit nos méthodes ? Où nous expliquons qu’il faut de la méthode pour prendre un besoin ?

Oui, car franchement, si c’était aussi simple, nous le saurions ? Nous ne sommes pas non plus des ânes !!! (sic !)

Pour prendre un besoin, pour faire émerger le besoin du client, il est nécessaire d’être aguerri à cette pratique justement pour limiter le risque d’erreur.

Peut-on parler de besoin quand on a : « Je veux une lumière halogène sur mon bureau ! ». Ben, déjà ce n’est pas un besoin !!!!!!

Et oui, il s’agit d’une solution !

Le travail de l’analyste est de poser les questions afin d’obtenir le réel besoin ! Qui dans ce cas pourrait être : « je désire avoir plus de clarté sur mon bureau. », une lumière halogène sur le bureau est une des multitudes de réponse qui peut être donné !

Alors quand je vois quand je vois passer un message du type « Je cherche quelqu’un qui connait ACCESS pour développer un outil pour une copine, afin de lui fournir un outil pour la comptabilité de son commerce. « 

Comment dire ?

Je vais vous dire ce que je réponds à cela !

1. La comptabilité : il y a des règles donc on se fait aider par une personne qui s’y connait !
2. Pourquoi ACCESS ? Ben, sans doute parce qu’elle l’a dans la suite Office !
3. Il existe des outils dans le commerce tout fait ! Pourquoi ils ne répondent pas à son besoin ? Est-ce vraiment une demande spécifique ? Est-ce un problème de formation ?
4. C’est quoi son besoin ? (car là, on est aussi à la limite de la solution !)

Voilà à quoi nous servons à accompagner, à conseiller !

Non, nous ne sommes pas nul ! Nous avons une plus-value qui est le fruit de notre formation, de notre expérience !

Comprendre l'agilité #Agile #Comprendre #Origine

Dans cet article, je vais vous conter une petite histoire, l’histoire de l’agilité !

Il faut savoir qu’au départ, cela vient de la gestion de projet informatique, et plus précisément du développement logiciel.

Là, je vais vous raconter l’histoire de Théo, Théo c’est un chef de projet, la gestion de projet n’a pas de secret pour lui, il est expert !

Il doit réaliser le nouveau site internet de sa société. Pas de difficulté particulière pour lui, il dispose d’un cahier des charges complet, il va se lancer.

La 1ère chose qu’il fait, c’est de préparer le travail : trouver l’équipe, définir le planning…

Et voilà le projet sur de bons rails, vous ne trouvez pas ? Le planning est fait, il est détaillé , le projet sera terminé dans 6 mois !

Allez on démarre !

L’équipe commence à travailler sur le projet selon le planning réalisé par Théo, on avance, bien sûr, quelques soucis sont rencontrés, mais bon, rien de méchant…

Théo met à jour son planning, ouf, il avait prévu des tampons, donc pour l’instant tout va bien.

Mince, il n’avait pas prévu que le développeur principal se casse la jambe lors d’un WE ! Hum, pas bon pour le projet, il refait son planning… Plus qu’à annoncer un retard d’un mois !

Vous vous doutez bien que le client n’est pas content !

Voilà, au bout des 7 mois, Théo est fier, le site est prêt, il organise la démonstration à son client (la direction de la communication de son entreprise).

Et là ? Mais qu’est-ce qui se passe ? Le client n’est pas satisfait, Théo et son équipe n’ont pas bien compris son besoin !

Et nous voilà parti pour 6 semaines de correctif !

Cette petite histoire est très proche de la réalité malheureusement, le besoin du client évolue, n’est pas évident à comprendre, l’équipe n’arrive pas à respecter le planning qu’on a estimé !

Il existe une solution miracle ? Non ! Mais les méthodes dites agile vont permettre de diminuer un peu ces risques.

Comment ? En appliquant quelques règles du génie logiciel !

Pour mieux comprendre, on va reprendre l’histoire de Théo.

Théo doit donc refaire le site internet de la société. Pour cela, il va travailler de concert avec le client qui lui racontera l’histoire de son site ! C’est un dialogue permanent durant tout le projet.

Mais autre changement, il ne fera pas de planning ! Si un macro planning qui définira juste les grands jalons du projet (les versions par exemple).

Et pour le reste, il fera confiance à son équipe qui s’organisera toute seule. Oui, Théo n’aura plus à lui communiquer toutes les semaines les tâches à faire, l’équipe s’autogère, elle définit elle-même le travail à faire ! Bon, d’accord au début, Théo, il a du mal car il doit apprendre à lâcher prise sur le travail de ses équipiers, et accepter de perdre un peu le contrôle.

Mais en fin de compte, cela se passe bien. Théo utilise avec son équipe la méthode SCRUM qui préconise un certains nombres de cérémonials, quelques règles. Tout le monde a été formé.

Le développeur qui se casse la jambe ? pas grave on ajuste le « A faire », et on avance tranquillement !

Le projet avance, le client fait des retours réguliers (lors des cérémonials prévus) , il lui arrive même d’ajouter des demandes ou d’en supprimer. Le projet avance et au bout de 6 mois, l’équipe peut mettre une version du site en ligne, une version conforme aux souhaits du client.

Dans cette petite histoire, on voit quelques notions importantes des méthodes dites agile :

1. L’implication du client avec des retours réguliers lors des cérémonials
2. Responsabilisation de l’équipe (auto-gestion)
3. Lâcher prise de la part du chef de projet (bon, là, ce n’est pas écrit dans le manifeste, mais je pense que c’est hyper important !).
4. On s’adapte en permanence : on peut ajouter ou supprimer des fonctionnalités durant tout le déroulement du projet sans problème.
5. On livre à la date prévue, un logiciel qui fonctionne ! (voir mon article ….. Pour mieux comprendre ce concept).

L’agilité, c’est vraiment un changement d’état d’esprit pour tous les acteurs du projet et de l’entreprise (client, équipe projet, management).

Ce qui est important de retenir, c’est qu’il s’agit d’une méthode adaptable, flexible, axé sur le résultat et non sur comment on va le faire !

Envie d’en savoir plus ? N’hésitez pas à me contacter !

Gérer son planning avec EXCEL ? #PROJET #GESTIONPROJET #CHEFDEPROJET

Pour 80% des chefs de projet, l’outil de planification est EXCEL.

Mais souvent, on entend : c’est galère de le faire avec EXCEL, cela prend du temps. Et le résultat est toujours le même : le planning n’est pas maintenu. Il ne sert à rien, si à faire jolie lors de la réunion de lancement.

Un planning ne sert que si on le met à jour régulièrement et que cela n’est pas une prise de tête à chaque fois !

Alors EXCEL ?

Ce que je dis : tout dépend de votre projet et du niveau auquel vous voulez aller !

La première question à vous poser : Macro planning ou micro planning ?

Si vous voulez faire un micro planning (planning détaillé), oublié tout simplement Excel. Cela va être galère pour vous !

Par contre, pour un macro planning, pourquoi pas Excel propose même des templates. Mais on reste très général.

Il faut bien voir qu’avec Excel, il ne sera pas facile de modifier une tâche.

Vous gérez une équipe ?

Alors là, oubliez tout simplement Excel, votre suivi ne sera que galère !

Réellement, ce que je constate, Excel est l’outil numéro un pour faire un planning, mais souvent ben, il n’y a pas de suivi ou alors on réalise des tâches « longues » pour que soit plus facile à suivre.

Un vrai suivi de planning ne se fait pas avec Excel ! Quand l’on parle de planning en formation souvent tout le monde en convient. Mais alors comment faire ? Je vous parlerais des alternatives à Excel dans un autre article.

 

 

Le cérémonial le plus important de SCRUM (Pour moi) #Agilité #SCRUM #AGILE #GESTIONPROJET #CHEFDEPROJET

Il y a un cérémonial que j’affectionne tout particulièrement dans SCRUM, car il est pour moi, la force de cette méthode ! (J’utilise méthode car c’est comme cela qu’on le défini mais voir mon article « Méthode Agile ? Approche agile ? »)

C’est la rétrospective de sprint !

Pourquoi ? Car cela permet à l’équipe de s’améliorer, de progresser.

Durant une rétrospective de sprint, on va faire le bilan du fonctionnement du dernier sprint. Mais pas dans l’optique de se juger, mais bien, dans cette idée de s’améliorer, de progresser !

En agile, en scrum, on a le droit de se tromper, ce n’est pas grave, on va chercher ensuite des solutions pour s’améliorer, pour améliorer le fonctionnement de l’équipe !

On donne carte blanche à l’équipe pour définir son fonctionnement, pour progresser.

En méthode classique, j’insiste fortement sur la nécessité de réaliser les rapports de fin de projet. C’est même un rendu obligatoire pour mes étudiants en projet tutoré.

Et là, en SCRUM, il faut en faire mais avec une approche différente car ce n’est pas seulement le chef de projet qui fait le RETEX mais toute l’équipe. Et là, cela permet de vraiment faire évoluer les pratiques.

Car je dirais 1+1 = 3 et oui, on est encore meilleur à plusieurs !!

N’oubliez pas ce cérémonial, mais surtout, il ne doit pas être fait pour être fait. Non, faites le sérieusement, vous verrez, votre équipe progressera et cela ne sera que du bénéfice pour votre projet !

Méthode agile ? Approche agile ? #Agilité #GestionProjet #Méthode #Approche

J’ai un réel problème avec ce terme de méthode agile !

Pourquoi ?

Une méthode pour moi, c’est vraiment quelque chose qu’il nous faut respecter, appliquer. C’est quelque chose qui est très codifié.

L’agilité, c’est plus un état d’esprit, plus quelque que chose de modelable !

Alors, oui, certains vous diront : ben, il faut faire comme cela, c’est SCRUM qui le dit ! (ou une autre « méthode » agile.

A cela, je leur répond : n’est-ce pas le monde des bisounours de vouloir faire entrer SCRUM de force dans les organisations actuels ?

Ayant, l’occasion de voir en formation actuellement énormément de grandes entreprises, je constate que si j’avais ce regard sur l’agilité, ben, la plupart de mes stagiaires se dirait en sortant de formation : ben, c’est bien comme méthode, mais bon, nous on ne pourra pas l’utiliser !

Finalement, l’agilité peut être utiliser dans de nombreuses sociétés, mais pas en prenant une boule de bowling , et hop, on la lance ! Résultat  : Strike !!!!!! Mais dans ce cas, cela ne sera pas positif ! Car ce sont les équipes qui seront à terre et votre projet. En plus, ces personnes arriveront en formation en disant : cela ne marche pas ! c’est des conneries ! (j’en ai vu passer plus d’un avec cet avis sur l’agilité !)

Finalement l’agilité, c’est prendre une boule en pâte à modeler, et l’objectif est de faire rentrer cette boule dans votre projet, votre entreprise ! Mais vous l’imaginez bien : la boule de pâte à modeler, elle va s’adapter, elle va prendre la forme que vous lui donnerez !

Mais attention, oui, les méthodes agiles ont les adaptes à son entreprise, projet, équipe… Par contre, il est important de ne pas les dénaturer ! Il est impératif de garder l’état d’esprit, de garder en tête ce que contient le manifeste agile, mais après on module, on adapte  !

C’est pour cela que je préfère parler d’approche agile, car à mon sens, nous ne sommes pas dans  quelque chose qu’il faut impérativement respecter, de normé !

Vrum vous connaissez ? #GestionProjet #Agilité #Classique #Chefdeprojet

Une méthode de gestion de projet, que je viens de découvrir ! Du moins, je viens d’en découvrir le nom. Pourtant c’est ce qu’il m’arrive de proposer comme solution en formation !

Vrum, c’est la contraction de : cycle en V et Scrum !

Oui, car on voit aujourd’hui beaucoup d’entreprise qui désire aller vers l’agilité mais, elles doivent respecter leurs processus (souvent très complexe). Leur métier ne leur permet pas de s’affranchir de certaines étapes de conception / validation, alors on va réaliser une grande partir du projet selon le cycle en V, et ne mettre en place que l’approche SCRUM pour le développement !

Dans mon approche, je propose de démarrer un projet en cycle en V, et de passer en Scrum quand les processus le permettent, c’est-à-dire par uniquement pour le développement.

Oui, on peut très bien réaliser le cahier des charges en classique puis passer tout de suite après en SCRUM (ou autre méthode agile, à votre convenance.)

Cette approche permet à mes clients de coller au plus près de leur organisation.

Pensez-y si jamais la mise en place de l’agilité n’est pas évidente dans votre organisation !

Halte à une idée reçue sur l'agilité ! #Gestionprojet #Agilité

Souvent on entend « L’agilité, c’est génial, on tient toujours les délais ! »

Ben, tout le monde sait qu’en méthodologie classique ben, le gros problème c’est le respect du triangle d’or (Qualité, coût, délais).

Et en agile, on est toujours dans ce triangle d’or !

Ça c’est le truc qui fait super plaisir au manager, responsable  : tous les projets se terminent dans le triangle d’or !!! Allons tous faire le grand plongeon de l’agilité !!!

Oui, mais voilà, ce n’est pas aussi simple ! Quoi, mais on m’aurait menti ?

Si on analyse bien, c’est la vérité tous les projets agile terminent dans le triangle d’or !

Mais vous pensez que c’est la potion magique ???

J’ai le regret de vous dire que non !

Un projet avec une méthode classique, c’est un besoin, une méthode, un produit que l’on livre à la fin. Souvent, on livre la Limousine avec toutes les options ! Bon d’accord on livre en retard, cela nous a couté hyper cher, mais purée notre client il a l’outil du tonnerre avec toutes les options… Ok, je vous l’accorde, il n’avait pas besoin de la majorité des options, mais purée, nous les concepteurs, on s’est fait plaisir. C’est kiffant vous ne trouvez pas ?

Souvent, on a le droit à la douche froide, car sa limousine, on lui a livré en bleu, et lui il l’a voulait en rouge… Mince quelle déception, en plus, il n’est pas content…

Cette situation est habituelle !

En agile, on va partir du besoin du client, et ce qui va compter en fin de compte c’est la satisfaction du client ! C’est lui livrer le produit qu’il a vraiment besoin quand il en a besoin et conforme à son budget ! Oui, cela fait rêver !! Mais il n’aura pas la limousine, il aura la simple berline avec juste les options nécessaires et à la bonne couleur !  (ben, oui, on aura fait avec lui des points réguliers, il nous aura donné l’information avant la fin du projet !)

Et oui, c’est cela le secret ! On ne lui livre que l’essentiel, que ce dont il a vraiment besoin, ce qu’il va utiliser !

Donc, quand on parle de la magie de l’agilité, il faut être conscient qu’on ne livrera pas la même chose ! Car s’il faut 18 mois en méthode classique pour réaliser un projet, en agile, on ne va pas mettre 10 mois. Oui, on va livrer quelque chose au bout de 10 mois mais cela ne sera pas la même chose que ce qu’on livrera en méthode classique au bout de 18 mois. C’est cela le secret, pour notre client, sa voiture, elle fonctionnera, elle répondra à son besoin, elle contiendra l’essentiel ! Mais bon, il n’aura pas de limousine qui finalement ne lui servira pas vraiment, en plus, cerise sur le gâteau comme vous lui aurez présenter régulièrement votre avancement, il aura la bonne couleur, il sera content ! Votre manager aussi sera content :  ben, oui, le projet aura été livré en temps et en heure, et le coût aura été respecté !

Tout va bien ???

Oui, si tout le monde est conscient dès le départ qu’on livrera pas la limousine !

Mais si cette notion n’est pas comprise, cela va coincer à un moment ou un autre.