87% of practitioners feel Prince2 has been useful to their career (2016 Prince2 Report)

QRP International France
Partenaire de DantotsuPM

« The report will help you put to bed certain myths that occasionally surround Prince2 » says Nikos Paxos, Head of PPM, Axelos Best Practices

Last month, AXELOS conducted its 2016 PRINCE2 Report.

Over 2,400 practitioners took the time to complete the survey and Axelos collated and analyzed the results which you can look at by yourselves.

  • 86% of practitioners feel that PRINCE2 has helped them in their current role
  • 87% of practitioners feel it has been useful to their career
  • 74% of individuals saw the value of agile

Keith Richards, lead author of PRINCE2 Agile®, explores the question “Is PRINCE2 Agile right for me?”

Some of the key topics and questions covered during the webinar include:

• A number of the key findings from the recent AXELOS market research study into project management
• Is agile right for me and my organization?
• How should you start a PRINCE2 Agile project?
• The PRINCE2 Agil-o-meter; how much agile can or should I use?
• How does the Minimum Viable Product (MVP) relate to the Business Case?
• Can I benefit from PRINCE2 agile in a traditional waterfall environment?
• How does it compare to other approaches such as AgilePM and Agile at GDS?

Partenaire de DantotsuPM
Partenaire de DantotsuPM

To discover more about the attitudes and trends shaping the Project Management industry today, download Axelos market research report.

Download Axelos 2016 PRINCE2 report

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Vaut-il mieux un livrable parfait et en retard qu’acceptable et dans les temps ?

Dans la plupart des sociétés et organisations la réponse est « acceptable et dans les temps ».

Read this master book on the suject
Read this master book on the suject

En effet, les dérives du perfectionnisme peuvent être coûteuses pour l’entreprise car admettons-le, tout livrable : article, email, vidéo, morceau de code, produit… peut toujours être optimisé et amélioré. Cependant, il advient aussi toujours un moment où vous devez le livrer.

Aussi, comme le prônent les méthodes Agile et les concepts tels que le Produit Minimum Viable (MVP), respecter un délai sans être paralysé par la recherche de perfection est vital pour l’entreprise.

Si cette question vous est posée lors d’un entretien de recrutement, il y a de fortes chances pour que la réponse attendue soit « ça dépend… ».

Indiquez certains cas où la recherche de qualité éventuellement poussée jusqu’à la perfection est louable et d’autres pour lesquels le timing est primordial.

Efforcez-vous de puiser vos exemples sur du concret, du vécu lors de projets passés ou d’échecs et succès retentissants.

perfectEn effet, la capacité à prendre du recul et à balancer le pour et le contre en toutes circonstances est une qualité très recherchée chez les chefs de projets et les leaders.

contactez-nous pour publier une annonce
contactez-nous pour publier une annonce

que se passe-t-il si votre nouveau projet nécessite vraiment « d’avoir fait polytechnique » ?

So What Happens When Your New Project Really Is “Rocket-Science”?

http://www.pmhut.com/so-what-happens-when-your-new-project-really-is-rocket-science par Kiron D. Bondale

Félicitations – on vient de vous donner l’occasion de manager un projet très novateur – si unique, en fait, que rien de semblable n’a jamais été essayé par votre organisation !

mathematicsUne fois passée la phase de l’euphorie initiale, vous réalisez le défi significatif auquel vous faites face : comment allez-vous planifier un projet sans le bénéfice d’être un expert ni avoir un historique de connaissances ? Pour empirer la situation, ceci est un projet que votre société réalise pour un client payant, il risque d’y avoir des pénalités tangibles et/ou impacts de réputation si vous manquez l’objectif de façon significative.

En supposant que vous ayez bien fait votre recherche et que la connaissance de projets semblables ne soit pas facilement disponible à travers votre réseau professionnel, ni vos associés ni autres sources en ligne, certaines des pratiques suivantes peuvent tout de même vous aider.

Campana & Schott est partenaire de DantotsuPM
Campana & Schott est partenaire de DantotsuPM
Faites articuler clairement à votre client l’état final minimal qui sera acceptable et aidez-les ensuite à vous donner une idée de la priorité relative de toutes les autres fonctionnalités annexes. Ceci peut vous aider à concentrer votre équipe les besoins impératifs sans être submergés par les moins critiques.

customer satisfactionImpliquez votre client dans la décomposition du contenu des livrables. Ils ont probablement passé considérablement plus de temps à réfléchir au sujet que vous ou votre équipe ne puissiez l’avoir fait. Et, bien qu’ils ne sachent pas substantiellement vous aider à déterminer « comment le faire », ils devraient pouvoir améliorer votre compréhension du « quoi faire ».

Plus le projet est novateur, plus large devrait être les compétences et expériences des invités aux sessions de planification. Vous ne savez pas ce que vous ne savez pas, aussi, en augmentant la diversité, vous devriez voir une augmentation de la qualité de la définition de la portée et de sa décomposition ainsi que l’identification de bonnes approches pour livrer ce contenu.

Appliquez des techniques comme Delphi pour pouvoir affiner et distiller des estimations.

Image courtesy of pakorn / FreeDigitalPhotos.net

Conduisez les sessions d’identification des risques avec un panel aussi large que possible. Ceci fera apparaitre des risques que vous ne pouviez pas avoir considérés, et aidera à surmonter des préjugés et peut même aider à identifier des éléments de contenu qui ont été manqués à l’étape précédente.

Structurez le projet en de multiples phases. Commencer par livrer un prototype, un pilote ou le modèle de l’état final désiré avec des estimations détaillées et le plan de développement pour livrer le projet en entier.

Partenaire de DantotsuPM
Partenaire de DantotsuPM
Adoptez des pratiques agiles et approchez-vous le projet comme un jeu d’itérations ou de sprints avec pour focus de livrer le contenu utilisable client de priorité la plus haute d’abord. Ainsi, si vous vous retrouvez vraiment à une forte probabilité de dépassement de budget ou de retard sur l’échéancier, le client décider de limiter ses pertes tout en recevant toujours la valeur du travail achevé à ce jour. Il est aussi recommandé de se concentrer sur les risques les plus importants et les besoins impératifs en premier. Les atteindre boostera le moral de l’équipe et l’expérience acquise sur ceux-ci pourra vous aider à revoir plus précisément le budget et les délais.

space-desk-workspace-coworking-largeAutant que possible, négociez pour obtenir des conditions de travail optimales pour votre équipe qui soutiennent au mieux la créativité et la productivité. Vous pouvez devoir demander à votre client ou votre sponsor des dérogations sur certaines des procédures standard d’exploitation de votre organisation si cela signifie que votre équipe pourra faire atteindre sa cible d’une manière plus prévisible. Mettez en place un « centre de crise » pour le projet (« Warroom »), un site de collaboration en ligne ou toute autre tactique (physique ou virtuelle) pour réduire la distance entre les membres de l’équipe et augmenter le partage de connaissances.

Comment manger un éléphant ? Une bouchée à la fois !

Projet Maximum Faisable

Do-able

http://sethgodin.typepad.com/seths_blog/2015/05/do-able.html par Seth Godin

Image courtesy of Michal Marcol / FreeDigitalPhotos.net
Image courtesy of Michal Marcol / FreeDigitalPhotos.net

Les Lean entrepreneurs parlent de MVP (minimum viable product: produit viable minimal), mais bien plus important est le Projet Maximum Faisable.

Étant donné les ressources à votre disposition (vos moyens, votre temps, votre patience), quel est le plus gros résultat que vous pensez pouvoir atteindre ?

Notre culture est organisée autour des gens qui sont là où on les attend, qui tiennent toujours leurs promesses, qui délivrent. “Très probablement” est en effet une approche confortable.

shooting at targetDomino Pizza pourrait avoir offert la livraison en 5 minutes, et parfois, sans doute, ils auraient réussi. Mais promettre quelque chose qu’ils pouvaient répéter quasiment à chaque fois leur a valu un numéro court d’appel mémorisé sur des millions de téléphones.

Viser trop haut est juste une tactique aussi néfaste que viser trop bas. Avant de promettre de changer le monde, il est raisonnable de d’abord commencer par changer votre quartier.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Faites ce que vous dites, puis faites-le encore, et encore mieux.

Nous avons besoin de vos rêves, mais nous avons aussi besoin de vos actes.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

5 règles pour une approche plus Agile du management de projet

5 Rules for a More Agile Approach to Project Management

http://www.pmhut.com/5-rules-for-a-more-agile-approach-to-project-management par Joanne Wortman

Voici quelques règles à suivre si vous voulez promouvoir le management de projet de façon Agile dans votre organisation

1. La fluidité est clé : La rigidité peut étouffer la progression des projets.

Diversité
des compétences diverses

Des structures traditionnelles demandent des définitions a priori des rôles et des responsabilités. Dans beaucoup d’organisations qui réussissent bien, ces modèles ont changé vers des structures plus collaboratives. Les équipes efficaces sont construites avec des personnes multi compétences plutôt que des spécialistes en silos. Un tel modèle de dotation en personnel fournit plus de chances d’équilibrer la charge de travail avec agilité pendant le cycle de vie d’un projet et peut améliorer la capacité de l’équipe à livrer le projet dans les temps.

2. Manager les attentes de vos parties prenantes est plus important que manager votre équipe projet.

Supposons que vous avez une équipe qualifiée et un plan bien écrit de projet. Devriez-vous passer le plus clair de votre temps à microgérer et suivre le statut de chacun de leurs mouvements, ou ajouteriez-vous plus de valeur en communiquant plus souvent et plus directement avec vos parties prenantes ? Arrêtons de considérer la communication comme « une compétence douce » (« soft skills ») et reconnaissons-la comme un activateur clé du succès des projets.

3. Le changement n’est pas un mal nécessaire.

Typiquement, le management de projet voit les requêtes de changement comme un mal nécessaire, mais le niveau d’agilité requise dans la plupart des entreprises pour survivre font des changements de contenu une Bonne Chose d’un point de vue business. Le management de projet classique fournit une structure pour exécuter des changements de contenu et les bons chefs de projet abordent les requêtes de changement, calmement, cordialement et sans attitude de tension ni dédain.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

4. Les outils collaboratifs ne remplacent en aucun cas les interactions entre les personnes de votre équipe ou parties prenantes.

discussion à la machine à caféLes alertes par courrier électronique, portails de projet, applications sur tablette donnent de la visibilité sur le statut du projet est sont de supers outils. Mais parfois, la meilleure façon de rester au fait du progrès reste de passer dans les bureaux avec vos listes de tâches et problèmes pour obtenir des mises à jour de statut par des conversations informelles. Le point positif est que cela vous permet de garder un doigt sur le pouls des personnes qui sont importantes pour votre projet et de promouvoir un meilleur engagement. Un appel téléphonique aux membres de l’équipe à distance est toujours apprécié. Ceci est particulièrement important avec des cadres exécutifs. Envoyer des salves de courriers électroniques demandant des mises à jour de statut n’est pas le signe d’un bon chef de projet.

5. Moins = Plus.

La pensée Lean est omniprésente. Dans la communauté des entrepreneurs, tout se rapporte au produit minimal viable. La méthodologie Agile a poussé des projets en direction du Lean, chaque itération étant une sorte de livraison minimale viable. Dorénavant, pensons à la structure minimale de projet. Plutôt qu’ajouter des éléments à une méthodologie, pensons à ce que nous pouvons enlever pour mieux faire, plus rapidement, moins cher.

 Relisez ce billet : pensons Produit Minimum Viable (MVP)

les projets dans la Construction comparés à ceux du Développement Logiciel

Construction vs Software Development

http://www.pmhut.com/construction-vs-software-development par Jerry Keusch

Ayant passé 30 ans dans la construction, j’ai pensé que je dédierais mon premier billet à une comparaison entre l’industrie logicielle et celle de la construction. J’ai listé mes 5 principales différences et similitudes et ensuite récapitulé avec 5 observations clés.

Les 5 principales différences

  1. Physique versus Virtuel

living-near-the-park2Sur un chantier vous n’avez pas besoin d’un diagramme pour voir le progrès : Il prend forme juste face à vous. Dans un bureau de développement logiciel, cela prend un peu de temps de s’habituer au fait que tout le monde passe leur journée devant un écran. C’est la différence entre la construction d’un produit physique et d’un produit virtuel.

  1. Ressources versus Connaissance

travailleur de la connaissanceUn projet de construction est avant tout du déploiement de ressources rares et de valeur; matériels, usine et main-d’œuvre. Un projet de génie civil majeur peut exiger d’énormes quantités de matériels et de lourdes machines. En comparaison, le développement logiciel exige seulement quelques personnes douées et des sièges raisonnablement confortables. En rapport, c’est bon marché.

  1. Séquentiel versus Modulaire

La construction est un processus ‘en cascade’, d’abord vous creusez un trou, puis vous coulez les fondations. Chaque étape est nécessaire pour pouvoir ‘cascader’ à l’étape suivante du programme de projet. Le Logiciel est en grande partie modulaire. Vous pouvez construire les parties (fonctionnalités) séparément et les coller ensuite ensemble.

  1. Produit Final versus Produit Viable Minimal

Probablement le plus proche du Produit Viable Minimal (MVP) dans la construction est une maquette. Il n’est tout pas simplement rentable de construire un petit pont au-dessus d’une rivière juste pour découvrir si les gens l’utiliseront pour passer de l’autre côté. Dans le développement logiciel, l’inverse est vrai, un MVP est idéal pour évaluer la demande et collecter du retour des utilisateurs.

  1. embouteillageOpérer versus améliorer

Quand le ruban est coupé sur l’autoroute et que le trafic commence à circuler, l’entrepreneur passe au projet suivant. Dans le développement logiciel, quand le produit est sorti, ceci est souvent juste le premier pas d’un long cycle continu de développement de versions et de support.

Les 5 premières ressemblances

  1. Suppression d’un obstacle

éliminer tous les obstaclesLes projets de construction suppriment d’habitude un obstacle, si cet obstacle est une rivière ou une montagne, la solution les traverse. Le bon logiciel fait de même, il supprime un obstacle, il résout un problème, il améliore l’expérience de l’utilisateur.

  1. Augmentation de la complexité

L’ajout de rangées de briques et de lignes de code font tous les deux la même chose, ils ajoutent de la complexité. Les projets de construction et les projets de développement logiciels partagent le même destin quand les choses tournent mal, ils peuvent devenir terriblement chers.

  1. Équipes

teamworkLes équipes de construction et de développement logiciel semblent un peu différentes, mais la dynamique de travail d’équipe est la même. Les supers équipes bossent bien, les mauvaises sont nulles.

  1. Processus et Management de projet

Ceci est la similitude que je dois remercier pour m’avoir permis de trouver un nouveau travail : les deux disciplines exigent des chefs de projet. À leur cœur est un processus et même si le domaine est différent, le processus partage des artefacts et des rituels communs.

  1. Défauts

Comme un constructeur déteste les accrocs, un développeur déteste les bogues.

5 Observations Clés

  1. Belles Solutions

bridge the gapJ’aime le fait que comme un pont, le bon logiciel supprime des obstacles. Dans l’architecture, la forme suit la fonction et j’ai déjà eu la chance de voir comment des développeurs créatifs et doués peuvent construire des solutions simples, belles et intuitives afin de résoudre des problèmes.

  1. Potentiel lucratif

Le développement logiciel est une industrie bon marché. Étant donné que le logiciel peut être vendu à un million de personnes à peu près au même coût qu’à cent personnes, ceci fait du développement logiciel une industrie avec des marges bénéficiaires potentiellement phénoménales.

  1. Tester d’abord le marché !

Le défi est bien sûr de construire l’application qui tue ! Avec la capacité de construire un Produit Viable Minimal pour tester la demande du marché, il est presque inconcevable que ceci ne soit pas un passage obligatoire avant qu’un projet n’entre en pleine production. Cela pourrait empêcher beaucoup d’échecs onéreux, après tout, rien ne motive autant que le succès.

  1. Construire des équipes hautement performantes

inspirer, enthousiasmerLe développement logiciel est une affaire de personnes, mais c’est encore plus une affaire d’équipes. Peut-être, que dans un business où les seules ressources sont les personnes, la meilleure formation est de construire des équipes hautement performantes.

  1. Collaborer

Le nouveau paradigme de réseaux fortement connectés détruit les structures hiérarchiques traditionnelles. Comme le développement logiciel amène des avancées dans la technologie, il est impératif qu’il embrasse les nouvelles formes de collaboration pour piloter l’innovation et donner vie à des équipes diverses et fortement distribuées.

pensons Produit Minimum Viable (MVP)

MVP Thinking

http://brodzinski.com/2013/06/mvp-thinking.html par Pawel Brodzinski

the lean startupUn des buts atteints par Eric Ries’ Lean Startup’ et porteur du plus de valeur est de populariser le terme de « Minimal Viable Product » (MVP), ou Produit Minimum Viable en français. Bien sûr le concept n’est pas nouveau. Nous utilisions l’idée de « Minimal Marketable Feature » (MMF) depuis les tous premiers jours de Kanban et elle était basée sur la même façon de penser. Il y a aussi davantage de concepts similaires.

La prémisse de base est que nous devrions construire la chose la plus petite possible ou faire fonctionner l’expérimentation la plus petite possible qui reste raisonnable et ajoute de la valeur. Selon le contexte la valeur peut être quelque chose qui aide des utilisateurs, mais peut aussi être simplement la découverte de nouvelles connaissances ou la vérification d’une hypothèse.

Une chose que j’ai réalisée récemment est à quel point j’applique largement cette pensée. Initialement, c’était simplement la façon de décomposer le contenu. J’ai voulu que mes équipes construisent des morceaux de logiciel probablement petits, mais toujours de valeur, et qu’un client puisse donc vérifier et nous donner un retour avec des informations utiles. Alors, après Lean Startup, il s’agissait de faire fonctionner un produit. Ce que nous voulons construire est quelque chose de nouveau qui frappe les esprits. Quelle est la fonctionnalité la plus petite qui peut prouver ou réfuter l’hypothèse que cela puisse fonctionner ?

D’une façon ou d’une autre j’utilise maintenant la même façon de penser, la pensée MVP si vous voulez, pour discuter des idées de marketing, définir des plans d’action pendant des rétrospectives, etc. Souvent il est difficile de définir un produit en soi, mais il y a toujours une idée des résultats attendus et un effort minimal définissable permettant d’obtenir ce résultat.

Ainsi comment définirais-je la pensée MVP ?

quelle est la cible à atteindre?1. Définir le plus petit prochain objectif de valeur que vous voulez réaliser.
2. Définir l’effort minimal qui vous permettra d’atteindre ce but.
3. Exécuter.
4. Analyser les résultats et apprendre.
5. Itérer.

Une partie potentiellement délicate est la définition de l’objectif parce que c’est totalement contextuel. C’est aussi quelque chose qui me plaît vraiment car je n’aime pas les recettes toutes prêtes. En fait, s’il y a quoi que ce soit de nouveau ici, c’est essentiellement l’application extrêmement large du modèle car l’idée elle-même n’est pas nouvelle. Je veux dire, nous limitons d’habitude notre contexte de travail au périmètre d’un projet, au management d’un produit, à faire tourner une affaire, etc. Alors, nous inventons un nouveau terme et s’il marche nous en faisons nos carrières de consultants excessivement bien payés.

Ce n’est pas du tout mon but. J’essaye juste d’élargir un contexte applicable d’idées que nous connaissons déjà et que j’ai personnellement trouvées utiles.

résolution de problème

Donc si mon problème est une fuite sous le toit près d’une lucarne, mon objectif minimal suivant peut être de vérifier si la fuite a un rapport avec un volet externe. Un tel objectif est acceptable parce que l’effort minimal peut être simplement d’attendre l’averse suivante avec le volet ouvert ou fermé. Je ne me précipite certainement pas pour réparer le toit.

marketing

shoutSi nous parlons de marketing ? Donnons un objectif général, disons: TechCrunch parlera de nous. Quelle serait l’expérimentation de valeur la plus petite qui pourrait nous rapprocher de la réalisation de cette sorte d’objectif ? Je suppose qu’étendre et manager son réseau peut être une première étape très raisonnable. Cela n’exige même pas d’avoir une idée, sans parler d’un produit, que nous voudrions voir couvert.

développement de produit

Que diriez-vous d’un produit ? Eh bien, celui-ci a été couvert pratiquement partout. Construire la fonction minimale, probablement même une simulation, qui permet de vérifier que l’idée pour le produit a du sens.

leçons apprises

Rétrospectives ? Quel est le simple, plus petit possible, changement qui aura un impact positif sur l’équipe ? Essayez-le. Vérifiez-le. Répétez.

achats

Zut, j’achète même mon équipement de marin de cette façon. Quel est le plus petit jeu d’équipements possible qui donne une chance de survie raisonnable ? Puis, j’utilise le résultat et je réitère, par exemple la prochaine fois j’aurai besoin de nouveaux gants, de caleçons longs  et de protection imperméable pour un téléphone.

kaizenQuand vous y pensez c’est essentiellement du Kaizen – faire systématiquement de petites expériences d’amélioration partout. Alors oui, il n’y a rien de nouveau. C’est seulement l’idée spécifique de Produit Viable Minimal qui me parle personnellement et m’a donné une contrainte agréable qui peut être utilisée dans les différents domaines de ma vie.

À propos, malgré sa définition très ouverte je trouve aussi que Kaizen est d’habitude appliqué dans un contexte très limité. Aussi, peu importe quelle idée marche pour vous, souvenez-vous juste que vous pouvez l’utiliser dans un contexte beaucoup plus large.