Actualités

Combien perdez-vous sans notre méthode de gestion de projets ?

  •  
  •  
  •  
  • 1
  •  
  •  
  •  
    1
    Share

Combien d’argent perdez-vous chaque année parce que vous n’utilisez pas notre méthode de gestion de projets pour améliorer vos marges ?

Quelle méthode de gestion de projets allez-vous choisir parmi les quelques dizaines de méthodes et outils existants ?

Ou peut-être vous n’en avez pas vraiment ? Ou peut-être ne trouvez-vous pas cela important ?

Ou peut-être voudriez-vous améliorer cela, structurer et maîtriser votre activité grâce à une vraie méthode de gestion de projets ?

Mais il y a trop de choix et vous ne savez pas par quoi commencer ?

Lisez ce qui suit pour commencer le chemin vers votre EXCELLENCE OPERATIONNELLE et améliorer vos marges immédiatement grâce à notre méthode de gestion de projets.

Nous allons donc rechercher et construire ensemble une méthode idéale et pratique pour gérer vos projets et vos produits, en partant de l’existant et de notre expérience, y compris la vôtre, lecteur averti.

Je classifie et résume les principales méthodes de gestion de projet existantes ci-dessous:

  • PRINCE2, pour PRojects IN Controlled Environment, est une certification mise au point par le gouvernement britanique et est surtout une méthode orientée processus appliquée au développement de grands projets IT. Prince2 compte 7 principes, 7 thèmes et 7 types de processus.
  • PMP, pour Project Management Professionnals,  est une certification US et est aussi une méthode orientée processus. Elle compte 10 domaines de compétence, 47 processus répartis en 5 groupes.
  • ISO21500 : le pendant européen de PMP, sans certification, énumère 39 processus répartis en 5 groupes, avec 10 groupes de sujets à prendre en compte dans la gestion de projets

Ces brillantes méthodes de gestion de projet sont de magnifiques outils de formation individuelle à des notions qu’il faudra vivre dans le feu de l’action et avec ses tripes pour en ressentir toute la portée et acquérir les réflexes. Ces méthodes de gestion de projet sont aussi avant tout fort intellectuelles et logiques, et ne prennent pas en compte les facteurs humaines, culturels, conjoncturels auxquels sont confrontés les projets dans la vie réelle.

De plus, ces méthodes de gestion de projet n’intègrent ni le fonctionnement en multi-projets qui utilisent des ressources partagées entre différents projets et la vente, ni la collaboration indispensable dans et entre les équipes-projets.

En conclusion, ces méthodes de gestion de projet sont très théoriques, très complexes et ne peuvent pas être appliquées telle quelle à une entreprise réelle.

  • La méthode en cascade (Waterfall): méthode en 6 étapes séquentielles, validées à chaque étapes, sans retour en arrière possible. Le cahier des charges ou la spécification de départ est censée être suffisamment précise / prédictif pour régler le déroulement de tout le projet.  Cette méthode de gestion de projets prône l’exécution du contrat sans interaction avec le client et les utilisateurs, qui découvriront les résultats à la fin. Originellement utilisée dans la construction et les travaux publics, cette méthode a trouvé ces limites récemment avec l’accélération du rythme du business, qui laisse moins de temps à la prédiction et la nécessité de vivre avec l’incertitude et les changements. Cependant, l’organisation en séquence est très utile pour assurer une convergence et un suivi du déroulement du projet.
  • Cycle en V :  ce modèle de gestion de projets est une amélioration de la méthode en cascade. Le problème de réactivité du modèle en cascade est adressé en ajoutant une vérification au terme ou en cours d’étape et permettre un retour en arrière à une étape précédente. Très utile de mettre en place une confrontation positive avec le client à certaines étapes-clé du projet. Ce modèle de gestion de projets est devenu un standard dans le monde de l’industrie depuis les années 1980.
  • Critical Path Method ou PERT : recherche du chemin critique et des chemins proches du plus critique. Le diagramme de Gantt permet aussi la détermination du chemin critique. Absolument indispensable pour connaître la succession des tâches qui impactera la date de livraison finale du projet.
Les méthodes agiles ont été proposées suite à l’avènement des développements logiciels, où les méthodes traditionnelles ne donnaient pas de résultats satisfaisants, notamment à cause de la lourdeur de la gestion des changements très nombreux dans le développement informatique et de l’éloignement du client/utilisateurs, ce qui ne donnait pas de résultats satisfaisant ceux-ci. Cependant, le développement itératif a l’inconvénient majeur d’être difficilement contrôlable, et que l’étendue du projet dérape et de s’adapter difficilement à la gestion des tâches. L’avis de Ron Jeffries, signataire du Manifeste Agile:  ‘Developers Should Abandon Agile‘.
 
  • Scrum: sans doute la plus puriste des méthodes agiles, et aussi beaucoup critiquée récemment, principalement pour son contrôle difficile quand elle est utilisée dans des projets de grande taille.  sa trop grande vulnérabilité adaptée aux petites équipes très expérimentées. Plus de détails pour étayer cet avis peuvent être trouvés ICI et ICI.
  • Cycle en spirale: par le développement de version successives, le cycle recommence en proposant un produit de plus en plus complet et robuste. Très utile pour le développement de versions successives d’un produit, mais attention à la guidance et contrôle d’un projet, comme discuté ci-après.
  • Roue de Deming – Plan Do Control Actindispensable routine des projets, à réitérer tout au long de la gestion de projet. Chaque étape de la méthode WinWin comprend ces 4 éléments de la roue de Deming.
  •  KANBAN, qui signifie étiquettes en japonnais: il s’agit en fait de ‘to do list’ dynamiques,  orientée actions, réajustée au gré des résultats. Assistée par ordinateur et depuis quelques années par des plateformes SaaS: comme par exemple Trello. Très utile pour l’agencement des micro-tâches, mais pas vraiment adapté pour gérer de grands projets.

Plus pragmatiques, les méthodes agiles sont basées sur un développement essentiellement itératif et adaptatif en coopération constante avec le client, ce qui est assez positif. Elles sont cependant difficilement contrôlable.

Nous en retiendrons le pragmatisme, l’adaptabilité et la coopération constante avec le client, mais il faudra y ajouter un cadre de contrôle et le découpage en tâches.

Les méthodes agiles seront utilisées lorsque le résultat final à atteindre est particulièrement abstrait ou éloigné de sorte que plusieurs ‘couches’ ou itérations de développement soient nécessaires.

Le besoin peut être bien défini ou pas, mais à mon sens, le souci ne se trouve pas dans la définition ni même dans la compréhension profonde du besoin. La difficulté se trouve plutôt dans la définition du résultat à atteindre et du chemin pour y arriver. 

Les méthodes agiles adressent aussi à juste titre la perception toujours personnelle d’une certaine vision d’un résultat, qui doit plaire à une audience.

Ce point est très important, et je voudrais m’y attarder un peu pour bien en mesurer toute la dimension:

J’ai participé il y a quelques semaines à une présentation du Process Communication Model. La formatrice passe une diapositive montrant un bouquet de fleur avec cette question : que voyez-vous ? la plupart répond ‘un bouquet de fleurs’ et certains ‘des visages’.  Et c’est vrai qu’en y regardant mieux, il y avait des visages dissimulés dans le ‘blanc’ de la diapositive. Et les autres ne voyaient que cela, mais pas les fleurs. Ce petit exercice nous montre à quel point la perception peut être différente entre les personnes, et nous sommes tous persuadés de voir ce qui est juste et bon, selon notre propre perception. Pour aligner ces perceptions différentes dans un groupe, il faut du temps et une volonté de travail. Cela ne s’impose pas non plus. On peut le faciliter par des outils, mais la plupart du temps, il s’agit d’un travail intérieur.

C’est pour cette raison que le développement en itérations a son fondement lorsque le résultat à atteindre est abstrait et par conséquent fortement dépendant de la perception des acteurs, perception qui doit être alignée pour converger vers une acceptation.

C’est typiquement le cas en développement software, où, après un premier développement pendant lequel vous étiez confrontés à plusieurs défis techniques et conceptuels, vous y voyez beaucoup plus clair après la première version. Après avoir utilisé tous les boutons et fonctionnalités disponibles, vous trouvez qu’il est plus approprié de faire autrement. Il y a une grande différence entre la conception d’un logiciel sur papier ou même sur Visio en analyse fonctionnelle et son fonctionnement en réalité. Après utilisation en live, vous pouvez devoir changer la place de certains boutons, de certains menus, voir même de certains principes, qu’il n’aurait pas été possible d’évaluer sans un premier développement. Dans ce genre de développements où le résultat est flou, il est recommandé d’utiliser une méthode de gestion de projet itérative.

Typiquement, on définit le résultat minimum utilisable (Minimum Viable Product) que j’emprunte au Lean Startup d’Eric Ries , on le budgétise, on le développe, on le met en production, et on récolte le feedback d’utilisateurs qualifiés ou non.

Ensuite, après une période d’utilisation, on définit un changement par rapport à ce premier produit, que l’on budgétise, etc, pour enrichir le MVP de plus en plus de fonctionnalité les plus conviviales. C’est la technique que j’ai utilisée dans ma start-up et pendant mon expérience chez EMIXIS.

Je veux faire aussi le rapprochement avec la méthode ‘Design Thinking’, basée aussi sur le principe de la confrontation le plus tôt possible avec le client, les utilisateurs, le marché.

La méthode WinWin est aussi adaptée à ce développement. Toutes les sociétés devraient adopter ce principe.

Cette méthode est bien évidement très adaptée au développement software, mais peut aussi s’appliquer à la construction d’une usine, ou à toute construction par étape pour contrôler les risques dans un environnement incertain.

Par exemple : un groupe de chercheurs a mis au point à l’université un nouveau matériau. Ils réussissent à convaincre des investisseurs et lèvent 10 Meur pour l’industrialisation. A ce stade, il faut construire le MVP, càd arriver à synthétiser le nouveau matériau en quantité suffisante pour démontrer sa capacité à être industrialisé. On décide de construire 1/10 de la future usine de commercialisation pour ce faire.

Cet exemple pourrait être appliqué à bien d’autres domaines. Pour moi, le principe de l’agile est de ne pas construire d’office une usine à gaz chère qui ne sera pas utilisée. Puisque le résultat à atteindre est lointain, l’interaction avec les utilisateurs est inconnu, allons-y par étapes bornées en argent et en temps afin de limiter les risques, et appliquons-y aussi les principes Lean par la même occasion. Et chacune de ces étapes peut être un projet WinWin.

 

J’emprunte donc aux méthodes agiles la souplesse, le mode coopératif et réactif, la relation soutenue avec le client (qui deviendra notre réalité nr 1), mais sous le contrôle du cadre du contrat, que je laisse aux méthodes prédictives. 

Dans les cas de construction abstraites, la clé pour ne pas tomber dans une avalanche d’avenants est de procéder par itérations au forfait, dans l’intérêt des 2 parties, car au fur et à mesure que la connaissance de la chose à construire avance, il se peut que les spécifications changent. Il s’agit en fait de PHASER le projet.

Projets et Produits

La distinction et la frontière entre un produit et un projet n’est pas toujours bien comprise.

Un produit est un objet ou un service qu’un utilisateur ou un client peut utiliser tout de suite.

Tandis qu’un projet est un ensemble d’activités à réaliser dans une période de temps pour créer ou améliorer un produit ou un service.

Quand un produit est terminé, càd quand il peut être vendu dans son état actuel, il n’y a plus besoin d’équipe projet pour le développer. Si l’entreprise qui le fabrique est bien organisée, un produit est pris en charge de façon quasi-automatique par les processus de l’entreprise : le client passe commande, la liste de matériel est commandée par ERP/MRP, la fabrication/assemblage est planifiée et la chaîne de distribution se charge de la livraison. Evidemment, ici, je prends beaucoup de raccourcis car les défis sont autres : approvisionnement, optimisation de la chaîne, etc. mais il s’agit d’une autre problématique.

Il est souhaitable de nommer un ‘Product Manager’ pour suivre toutes les évolutions et ‘les maladies’ de ce produit ainsi que pour guider, anticiper les évolutions. L’exécution d’une commande d’un produit ne demande pas d’engineering, ni de personnalisation d’installation sur site. Dès qu’un élément de personnalisation client apparaît, il s’agit d’un projet. Ceci dans une mesure raisonnable bien sûr, car une équipe-produit peut s’occuper de quelques personnalisation/paramétrisation d’un produit, mais dès que plusieurs ressources interviennent, il faut passer en mode projet. Cette frontière est à établir de façon tactique et stratégique en fonction de chaque entreprise, selon ses besoins et son organisation opérationnelle.

Un produit se voit dans une continuité temporelle. Un projet non.

La continuité temporelle des produits est assurée par une ‘roadmap’.

2 approches ‘roadmap’peuvent être distinguées : une approche anticipative et une approche réactive.

L’approche anticipative consiste à prévoir de créer un produit ou d’ajouter de la valeur à un produit existant en prévision d’une attente soit présente soit latente d’un panier de clients potentiels ou actuels.

L’approche réactive consiste à aménager des produits existants ou à créer un produit à la demande d’un ou plusieurs clients.

Il est évident que la première approche comprend plus de risques que la seconde, tandis que la récompense des risques est la mise à l’échelle bien supérieure de la première approche, si le produit réussit à accrocher le marché.

En cas de roadmap anticipative, de nombreuses techniques de création et de validation de marché peuvent être utilisées, et ce n’est pas le propos de cet article. 

Les valeurs à ajouter au produit seront traduites en une spécification technico conceptuelle, sorte de contrat entre les imaginateurs et les réalisateurs. 

À mon sens, cette étape de formalisation écrite est essentielle pour plusieurs raison : 

1) les écrits restent, les paroles s’envolent. Même pour les meilleurs, la mémoire se distord avec le temps. 

2) souvent les idées primaires sont excellentes, et se compliquent trop quand la technique s’en mêle, 

3) excellente base pour un phasage des développements et tests, surtout dans le modèle économique Saas, pour apporter continûment de la valeur supplémentaire aux utilisateurs, 

4) permet d’améliorer la communication. Pas évident de communiquer entre ces 2 parties du business. Les uns veulent la lune et les autres une autre planète. 

Donc, sur base de la spécification technico conceptuelle, il est possible de planifier un ou plusieurs projets, d’abord de création du MVP, et puis d’amélioration graduelle du MVP en fonction des réactions du marché, et de construire une vue à moyen/long terme des moyens à mettre en œuvre pour y arriver. En ce sens, le développement en roadmap est une certaine forme de développement agile, avec des sprint contrôlés et validés, 

Une roadmap produit est bien-sûr un élément interne à l’entreprise et le plus souvent confidentiel.

La roadmap représente le cycle de vie des produits au travers de 4 grandes étapes : lancement, croissance, maturité et déclin. Mais ceci pourra faire l’objet d’un autre article.

Nous avons donc vu que les projets servent à créer un produit ou à ajouter de la valeur à un produit existant ou à paramétrer/aménager/installer un produit existant.

La méthode WinWin propose un cadre de fonctionnement pratique pour la vie des projets et la vie des produits.

Projet d’exécution et projet d’innovation

Nous poursuivons donc notre quête des principes d’une méthode idéale en incluant aussi les démarches très innovante et inconnues.

Un projet d’exécution vise à mettre en œuvre un cahier des charges, qui peut comporter certaines innovations. On peut considérer que le résultat est concret, matérialisable sur des plans, une maquette.

Un projet d’innovation vise à créer ce cahier des charges. Ensuite, un projet d’exécution prend le relais.

Un projet d’innovation comporte bien-sûr plus de risques qu’un projet d’exécution pure. Néanmoins, un projet d’exécution peut comporter quelques petites innovations incrémentale.

Je voudrais souligner qu’un projet d’innovation devrait toujours être encadré par une méthode.

On pourrait d’ailleurs y ajouter les projets de ‘troubleshooting’, qui peuvent aussi faire appel à de l’innovation. Et dans le cadre du troubleshooting, une méthode appropriée est salutaire, mais cette réflexion sort du cadre de cet article et j’y reviendrai peut-être plus tard.

Revenant sur les projets d’innovation, utiliser une méthode comme ‘Design thinging’, et un coach pour ce faire, permet de se rattacher à la première étape de notre méthode WinWin: la définition.

Et je recommanderais de structurer cette première étape selon la méthode d’innovation choisie, avec un planning, un budget, un partage équitable des coûts, le plus souvent en régie, entre les parties prenantes.

En effet, la créativité n’empêche pas une convergence et le suivi d’un planning. Car, dans le cas opposé, on peut créer, créer et s’emballer dans des égarements qui ne sont pas demandés ou qui n’ont pas été convenus (càd qui ne seront pas valorisables en plus).

Dans le cas d’une valorisation à postériori, on rentre dans une démarche de création de produit. La démarche est différente, car on itère pour créer un maximum de valeur pour un client ciblé futur, que l’on valorise à un prix étudié suivant différents critères.

Mais dans le cadre d’un projet d’exécution, que ce soit en informatique, en service ou en industrie, on réalise ce qui a été convenu dans un contrat à l’avance pour un certain budget.

Pour certains développeurs et créatifs, cela peut paraitre contraignant et ‘pas amusant’. Il s’agit d’ailleurs d’un conflit latent entre le project manager et certains membre de l’équipe dans un cadre trop agile.

Il s’agit d’un des dures réalités : il y a un contrat à respecter, tant du point de vue du client, à qui on veut faire plaisir, que du point de vue interne, car la société qui nous emploie doit gagner de l’argent.

Un projet d’innovation peut se gérer avec la même méthode qu’un projet d’exécution, même s’il ne ne gère pas de la même façon.

La méthode WinWin se combine avec un méthode de résolution de problème ou une méthode de stimulation et de guidance de la créativité dans le cadre d’un projet d’innovation.

Le biais des projets au forfait.
Le poids des modèles économiques.

Nous avons vu que les méthodes ‘traditionnelles’ ont été formalisées pour gérer des projets de construction physique, tandis que les méthodes Agiles ont été développées pour gérer des projets dont les résultats sont plus abstraits pour pallier à la rigidité du modèle en cascade et en V dans ces cas.

En même temps, la réalité économique s’invite dans notre réflexion : la rigidité vient aussi de la définition du projet comme un coût forfaitaire.

Dans un coût forfaitaire, sont définis un scope, un niveau de qualité (le meilleur bien sûr), une série de livrables documentaires et une marge, que le prestataire souhaite en tout cas maintenir pour gagner de l’argent et éventuellement maximiser pour grandir. Ce cadre est supposé être figé, dans un contrat. Et, en début de projet, tout le monde est bien d’accords.

Les risques ne sont pas partagés. Dès que le contrat est signé, les risques sont transférés sur le prestataire/fournisseur, qui a la mission d’exécuter le contrat.

Cette réalité du coût forfaitaire est une constante, sauf quand le client accepte ou souhaite fonctionner en régie, même contrôlée.

L’exception du modèle SaaS/Paas : dans le cas d’un développement SaaS et plus généralement, dans le modèle économique Saas ou Paas (Platform as a service), les utilisateurs paient un forfait fixe, le plus souvent mensuel, pour l’utilisation d’un service. 

Pour garder et étendre le nombre de ses utilisateurs dans un modèle ou les barrières à l’entrée et sortie sont par définition relativement faibles, et donc ses revenus, il convient d’ajouter graduellement de la valeur au service, et donc d’étendre/améliorer les fonctionnalités.

Les développements peuvent donc se faire dans une relative liberté. J’écris relative, car il n’y a pas vraiment un client ou des utilisateurs qui ‘exigent’ certaines fonctionnalités dans un certain budget.

Donc, pour rester contrôlable dès l’instant où les risques sont dans les mains du prestataire, un projet doit être basé sur un résultat concret et définissable, qu’il conviendra de définir dans un contrat.

La méthode WinWin recommande de scinder les projets abstraits en phases avec un résultat concret et au forfait. Chacune de ces phase est un projet WinWin.

Impliquer le client et éviter l'ingérence

Quand je parle du client, il s’agit d’une considération générique: le, les clients, l’équipe du client, les utilisateurs représentés par leurs super-users.

Personnellement, j’ai toujours impliqué mon / mes clients quand il s’agissait de software dans le développement de projets, en respectant le cadre qui avait été fixé au départ, et si ce cadre était dépassé pour une raison demandée par le client, une négociation commerciale avait lieu, avec ou non l’implication d’un vendeur lorsque nécessaire. Cette façon de faire atteint évidemment ses limites lorsqu’il s’agit de renégocier toute les semaines. Dans ce cas, le salut est de continuer en régie contrôlée, ce qui est possible dans un climat de collaboration rapprochée avec le payeur, ou de segmenter le projet en sous-projet au forfait chacun, et d’appliquer la méthode WinWin à chacun de ces sous-projets, quitte à alléger quelques étapes. Et encore une fois, ce cas de figure se présentera quand le résultat et le chemin pour l’atteindre est inconnu. 

S’emballer dans un projet complexe avec un résultat et un chemin inconnu est voué à l’échec.

Il est en effet aussi important de reconnaître que la vision et la compréhension des besoins et attentes peuvent évoluer au cours du projet, pour des tas de raisons, et pas uniquement la compréhension meilleure du produit.

Le problème est à ce moment : qui paie quoi ? faire et défaire, c’est toujours travailler. Mais qui paie la facture du temps passé ? pour moi, c’est là que réside toute la question, et les débats sur la flexibilité des méthodes est vain sans la résolution de cette question. On peut être très flexible, et contenter le client qui va et qui vient en explosant totalement le budget initial. Et on peut être très rigide en mécontentant le client.

 

 

C’est la raison pour laquelle, la méthode WinWin intègre le monitoring du client en première place.

En acceptant une certaine flexibilité en fonction de l’impact du changement, avec un oeil sur les risques, il est possible de contrôler le projet et de le réussir au-delà des attentes du client et du prestataire.

Tout l’Art réside dans cet équilibre : WinWin.

C’est pour cette raison que la méthode WinWin accorde tant d’importance au Project Status Report:

– Savoir reconnaître un changement

– Savoir reconnaître quand une somme de petits changements devient un gros changement, qui devient une déviation par rapport au contrat initial.

Car certains clients sont très malins, d’autant plus que parfois, il n’y a pas un mais plusieurs points de contact chez le client (c’est d’ailleurs à éviter, et l’investissement d’un key account manager est le plus souvent rentable).

Certains clients donc, sont passés maitre à demander des petits plus çà et là, parfois au terme d’une rude discussion avec plusieurs intervenants. Le danger est de rester sur la satisfaction de l’obtention d’un accord, parfois difficile, entre l’équipe du client et l’équipe interne, dans un délais le plus raisonnable possible pour ne pas impacter votre chemin critique, et ne pas se rendre compte qu’une dérive est possible. Dans ce cas, je recommande de toujours accepter ou conclure un compte-rendu de discussion ou de réunion avec le client dans laquelle vous avez du faire des concessions, par une phrase du genre ‘les éléments agréés ci-dessous n’empêche pas une discussion commerciale plus tard au vu de l’avancement global du projet’. Au final, on fera le décompte des plus et des moins. Mais soyez sur que les moins auront plus de poids que les plus. Malgré l’obtention d’accord de plus-value au contrat pour des parties de scope et travaux supplémentaires, je me suis déjà fait avoir, parce que le client avait promis de nous envoyer un supplément de commande, et que  

Donc, gardez-vous bien des promesses. Rien de tel pour acter un changement qu’un avenant de commande et une bonne facturation.

 

 

La méthode WinWin monitore le client en première place. Ce monitoring se passe dans le Project Status Report, à intervalle régulier d’un mois, avec les 5 autres réalités.

La méthode de gestion de projets WinWin

Alors comment se dessine cette méthode ?

La méthode WinWin se construit sur base des méthodes existantes les plus performantes. On pourrait donc la qualifier d’hybride sur plusieurs méthodes de gestion de projet, incluant au passage quelques techniques pointues.

La méthode WinWin fait partie des méthodes dites ‘Lean’ dans ce sens qu’elle préférera toujours quelques itérations proches des utilisateurs/clients à une grosse usines à gaz inutilisable.

La méthode WinWin est utilisable en exécution, innovation, implémentation et résolution de problèmes, principalement dans un souci d’efficience  pour ses utilisateurs: devoir maîtriser UNIQUEMENT UNE SEULE méthode de gestion de projets : la méthode WinWin.

La méthode WinWin est compatible avec les méthodes d’accompagnement: stimulation et de guidance de la créativité, comme notamment, le Design Thinking et avec les méthodes de résolution de problèmes (troubleshooting, comme DMAIC, AMDEC, TRIZ, etc).

La méthode WinWin s’applique à de petits et grands projets, ie de 10 keur à 500 Meur.

La méthode WinWin laisse une place au bon sens des gestionnaires en fonction du contexte, ce qui est absolument indispensable. Elle définit un cadre de travail flexible dans l’accompagnement de la convergence des parties prenantes vers un résultat qui convient au client dans le respect du prestataire.

La méthode WinWin se décline en 6 réalités au travers de 9 étapes, dont certaines facultatives suivant la taille et le type de projets et 5 principes simples. Retenez 695.

La méthode WinWin contient aussi une éthique de communication, Lean elle aussi, afin que les équipes projet restent concentrées sur leurs tâches en éliminant les distractions.

La méthode WinWin prend en compte l’environnement de ressources partagées entre différentes projets et avec la vente. 

La méthode WinWin consolide plusieurs projets et leurs ressources en un tableau de gestion de portefeuille de projets qui facilite la prise de décision.

Finalement et certainement le plus important pour vous:

1. WinWin se décline en outils pratiques et immédiatement utilisables: la liste de contrôle des documents, la maturité des livrables, les modèles de diagramme de Gant, etc

2. les outils WinWin s’implémentent directement dans un outil digital de gestion de projet et de collaboration.  Actuellement, c’est Genius Project qui répond le mieux à la méthode. 

Tous ces outils pratiques font partie intégrante de la méthode WinWin, et sont adaptables à chaque entreprise et à chaque type de projet.

La méthode WinWin s’implémente avec tous ses outils pratiques directement sur une plateforme collaborative de gestion de projets.

Faites savoir à vos chers réseaux que ce contenu vous a inspiré !
  •  
  •  
  •  
  • 1
  •  
  •  
  •  
    1
    Share

Frédéric Le Roux

Passionné par les réalisations en équipes, j'ai piloté en 18 ans des projets et développements de produits dans 5 industries avec des budgets jusque 60 MUSD. J'ai mis au point une méthode accompagnée d'un outil numérique et de la gestion du changement occasionné par leur implémentation au sein des organisations pour propulser leur EXCELLENCE OPÉRATIONNELLE.

  •  
    1
    Share
  •  
  •  
  •  
  • 1
  •  
  •  

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

19 + 7 =