Dans nos projets, posons-nous une question et posons-la surtout à nos parties prenantes et commanditaires : Qu’est-ce qui est réellement vital pour la réussite du projet ?
Cette exigence est-elle un carré de plus de chocolat ou bien l’oxygène sans lequel vous ne pourrez vivre ?
A propos des besoins vitaux et des autres besoins et de comment bien faire la différence par Seth Godin.
Soyez à court le chocolat et c’est la honte. Soyez à court d’oxygène et vous êtes foutus.
Parfois, nous exagérons notre dépendance au chocolat. Il est meilleur à petites doses : Trop et il perd de sa magie. Et parfois nous confondons la chose que nous voulons avec la chose dont nous avons besoin…
Si votre journée ou votre projet ou votre organisation se concentrent trop sur trouver le prochain carré de chocolat, vous pourriez oublier de vous concentrer sur l’oxygène dont vous avez en réalité besoin pour vivre.
Ce sont les clients pleinement satisfaits, delightedcomme le disent les anglophones, qui font votre succès et votre réputation.
Apprenons à choisir nos clients comme nos batailles et nos succès seront bien plus retentissants.
Pensons également à étendre cette maxime au niveau du portefeuille de projets pour apprendre à choisir nos projets : « Vaut-il mieux lancer 2 projets qui répondront à 100% des attentes de quelques clients précieux que ces 10 autres qui ne satisferont que partiellement un plus grand nombre de clients ? »
Hexagon est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Nous nous interdisons souvent trop de choses dans nos projets.
Nous avons une tendance naturelle à nous auto-censurer. Hors, pour dépasser les attentes de nos clients et de nos équipes projets, il faut souvent aller juste un peu plus loin que ce qui est demandé ou attendu: Livrables, qualité, délais, ambiance de travail…
C’est en étonnant que l’on peut faire une réelle différence dans le business et dans les relations avec ses équipes, sponsor et clients.
partagez ce billet avec vos amis, collègues et relations professionnelles
Selon PM Network de Juillet 2018, la dérive de contenu reprendrait du poil de la bête.
PM Network est une publication du Project Management Institute
“PMI,” the PMI logo, “PMP,” “PMBOK,” “PM Network,” “Project Management Institute” and “Pulse of the Profession” are registered marks of Project Management Institute, Inc.
En effet, force est de constater dans la pratique que nous (nous-mêmes, nos clients et les parties prenantes du projet) ne savons pas de quoi nous avons besoin quand nous commençons.
Le changement est naturel et de nouvelles choses et imprévus surviennent toujours. Le client a besoin de changement. Le business, nos concurrents, les innovations… forcent le changement. Des personnes extérieures à l’équipe projet proposent de nouvelles idées. Les membres de l’équipe ont de nouvelles idées. Le changement perpétuel est la seule chose sur laquelle nous pouvons compter.
Donc arrêtons de feindre de pouvoir l’arrêter ou l’empêcher et améliorions plutôt nos capacités, processus, approches et état d’esprit pour bien le manager.
Apprécions d’apprendre de nouvelles choses
Trouvons le bon équilibre entre réactif et proactif
Adoptons un rythme raisonnable pour prendre le temps de considérer de nouvelles idées et pouvoir changer de direction
La prochaine « dérive de contenu » (Scope Creep) à laquelle vous résistez pourrait justement être le changement qui transforme votre projet un succès retentissant !
avec Ventura Asssociates, partenaire de DantotsuPM, recrutez les ressources critiques dont vous avez besoin pour vos projets
partagez ce billet avec vos amis, collègues et relations professionnelles
Cela commence par “Pourriez-vous juste … ?”, “En ce qui concerne …” ou “ne me tuez pas, mais … ?”. Ce qui vient est ensuite une nouvelle idée, fonctionnalité, ou demande qui n’a pas été abordée auparavant. Cette conversation arrive tout le temps et cause beaucoup de bougonnement sur “la dérive de contenu”.
Mais si vous considérez l’étude et la découverte comme étant des parties naturelles du processus de développement de logiciel, il n’existe pas de dérive de contenu. C’est seulement un changement mal managé.
Nous ne savons pas de quoi nous avons besoin quand nous commençons. De nouvelles choses surviennent toujours . Le client a besoin de changement. Le marché force le changement. Des personnes à l’extérieur de l’équipe trouvent de nouvelles idées. Les gens dans l’équipe ont de nouvelles idées. Ce changement constant est la seule chose sur laquelle nous pouvons compter. Donc arrêtons de feindre de pouvoir l’arrêter et améliorions-nous dans bien le manager.
avec Ventura Asssociates, partenaire de DantotsuPM, recrutez les ressources critiques dont vous avez besoin pour vos projets
Appréciez l’apprentissage
Un des problèmes avec la terminologie « dérive de contenu » est qu’elle implique que nous n’avons pas fait assez bien notre travail. Elle implique que quelqu’un, quelque part, a failli et si nous étions de meilleurs managers, ce ne serait pas arrivé. Nous aurions prévu toutes les demandes possibles ou nous aurions la force ou la capacité de dire « Non » à chaque fois quelqu’un a une nouvelle idée. Elle implique que la dérive de contenu est un monstre effrayant qui doit être tenu éloigné par un chef de produit toujours vigilant qui garde jalousement la porte de grange.
Cela décourage le changement et l’apprentissage. Une des leçons du mouvement de développement de logiciel Agile est qu’il n’y a aucune façon fiable de spécifier à l’avance ce que nous devons construire. Apprendre sur les besoins est nécessaire pour pouvoir converger sur une solution idéale.
L’équipe de développement doit apprendre ce qui est possible en fonction des contraintes des outils et de la technologie disponible. Les chefs de produit doivent valider leurs suppositions sur quelles fonctions ou technologies particulières sont les plus susceptibles de répondre à un besoin, tandis que les consommateurs du produit ne savent souvent pas vraiment ce qu’ils veulent avant qu’ils ne le voient.
Nous pouvons penser qu’une solution donnée sera idéale quand nous la considérons sur le papier ou sur un tableau blanc, mais quand nous mettons une application entre les mains d’un utilisateur, nous obtiendrons toujours une compréhension nouvelle et plus profonde de ce qu’est la « bonne » chose à construire. Apprendre est quelque chose qui doit être recherché et pas craint.
Le management du changement est une compétence
Une équipe de développement a une capacité fixée et aucune quantité de désirs, de pressions ni de contraintes ne générera de production plus significative. Au lieu de cela, la gestion du changement réussie est l’art d’optimiser le travail qui est fait avec cette capacité.
Cela commence par un processus pour rassembler toutes les nouvelles idées, demandes et choses apprises à travers toute votre organisation. Des modèles apparaîtront, montrant quelles nouvelles choses sont les plus importantes. Le management du changement n’a pas pour objet d’agir sur toutes ces idées; il s’agit plutôt de trouver l’équilibre entre être réactif et disruptif.
Si nous avons un processus robuste pour gérer notre capacité, nous pouvons considérer autant de nouvelles idées que nous voulons, sachant que le processus exigera que nous nous engagions seulement sur ce que nous pouvons raisonnablement faire. Les équipes arrêtent de craindre la dérive de contenu quand elles se rendent compte que de nouvelles idées ne signifient pas automatiquement des nuits plus courtes.
Certaines nouvelles idées qui surgissent sont suffisamment bonnes pour remplacer de vieilles idées. Certaines ne sont pas aussi bonnes que ce que nous avons déjà, et nous devrions y renoncer. Et parfois l’union d’une vieille idée avec une nouvelle crée quelque chose de magique.
Finalement, nous avons besoin d’un rythme raisonnable pour considérer de nouvelles idées et changer de direction. Si une équipe consomme une grande partie de son temps chaque jour à considérer de nouvelles choses, elle fait probablement peu de progrès sur le livrable. Plusieurs méthodes agiles spécifient une période courte pendant laquelle aucun changement de ce sur quoi l’équipe travaille n’est permis. Mais tout est alors à prendre en considération aux frontières de cette courte période de temps.
La dérive de contenu est un ennemi imaginaire
Nous n’avons absolument ni le temps ni les ressources pour agir sur toutes les bonnes idées qui sont déposées sur la table pendant le déroulement du projet. Mais agir sur quelques-unes de ces idées peut être essentiel.
Alors, la prochaine fois une nouvelle demande arrive, arrêtez-vous et considérez-la. Cette dérive de contenu à laquelle vous avez résisté pourrait juste être la chose qui fait réussir votre projet.
partagez ce billet avec vos amis, collègues et relations professionnelles
And it is very true that as we become more and more expert in our discipline, whatever the discipline, we focus on its most complex and sophisticated aspects.
We look at advanced metrics and measures, calculations, processes…
However, we must remember that there are some very basic, some fundamental items which will kill our project if we loose sight of them.
In his article, Ty mentions:
Clearly defined business objective that is well understood by all.
Active executive commitment.
Shared determination to complete the project.
I would suggest to add:
A clear and simple project governance
Sound and unambiguous business requirements
Clarity on scope and excelling at managing change requests
The commitment to serve and satisfy the customer as our guiding rule
Ventura Asssociates est partenaire de DantotsuPM et le votre pour dénicher les ressources critiques en PM dont vous avez besoin
While managing the fundamentals may not sound very exciting, it often is what makes the difference between projects and project managers who are successful and those who aren’t.
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
La mentalité dominante dans le management et la finance dans les sociétés est de nos jours centrée sur l’efficacité, la productivité et les coûts.
La préoccupation majeure est de maximiser tous les actifs et capacités pour que rien ne reste inactif ou inoccupé.
Ce que ceci signifie vraiment est de garder les gens utilisés à 100 %.
Si la demande est là, cela a du sens de maximiser la production. Mais connaît-on vraiment la demande ?
Avec le développement piloté par les spécifications, il y a d’habitude l’implicite attente que toutes les fonctionnalités exigées soient exprimées.
Et si toutes les fonctionnalités construites n’étaient pas utilisées avant longtemps ?
Cela accroîtrait simplement le stock de capacités inutilisées.
Et si une proportion de ces fonctionnalités n’était jamais mise en œuvre par les utilisateurs ?
Ce serait un gaspillage d’argent et de ressources.
Toutes les demandes ne sont pas égales. Toute demande n’est pas fonctionnalité. Il vaut mieux supprimer toute demande qui ajoute un coût, mais peu de valeur.
Quels sont les différents types de travail et quels sont leurs besoins ?
Trouver l’équilibre entre la capacité et la demande signifie souvent que quelques actifs resteront inoccupés. Parfois certaines personnes se retrouveront avec un peu de temps libre entre leurs mains. Dans le domaine de la production, les coûts d’inoccupation sont généralement acceptés en échange d’une réduction de stock et des coûts liés au stockage et cela permet d’éviter les conséquences de devoir vendre la surproduction à prix cassés.
Le temps « mort » fournit un espace dont il devrait être fait bon usage.
Toute personne avec du temps libre a la responsabilité de s’assurer que le coût de ce temps « mort » est récupéré par des améliorations sur l’ensemble de la chaine de la valeur (incluant des améliorations de la façon de travailler et la suppression d’inefficacités) qui réduisent le coût de production et augmentent la qualité.
partagez ce billet avec vos amis, collègues et relations professionnelles
PMI recently launched a new practice guide on requirements management, which is available for free download for a limited time.
Requirements Management: A Practice Guide is a complementary document to the Project Management
Institute’s (PMI’s) foundational standards. This practice guide provides guidance for project and program managers
who are looking to further understand the components and importance of requirements management.
A Practice Guide is for your individual use only. It may not be shared, copied or otherwise distributed further without written permission from Project Management Institute. All rights reserved.
partagez ce billet avec vos amis, collègues et relations professionnelles
Nouvel atelier de Claude Emond en Gestion de Projet Agile des projets d’innovation et de développement de produits, en collaboration avec L’IDP.
Une approche comme toujours originale de notre ami Claude Emond: Sur 3 journées (4, 9 et 16 nov 2015) incluant, pour chaque participant, 3 heures de coaching personnel sur un projet de leur choix, pendant, entre et après chaque jour de formation.
Inscriptions et Détails
Objectif de cette formation-action
Outiller les gestionnaires de projets en développement de produits sur les techniques de gestion agile. Cette formation leur permettra d’accélérer leur projet, de mieux mobiliser leur équipe de développement et ainsi maximiser les bénéfices et le retour sur investissement.
Bénéfices pour les entreprises participantes
Préciser le rôle du chef de projets, en mode agile
Augmenter le taux de succès de vos projets de développement de produits
Maîtriser le savoir-faire qui permettra d’accroître votre efficacité en gestion de projets
Développer vos compétences pour mobiliser et guider les équipes de projets agiles vers le succès
Intégrer de nouvelles connaissances par la formation-action dans le cadre d’un projet en cours dans votre entreprise
Profiter de l’encadrement des formateurs entre les rencontres pour maîtriser les nouveaux outils et mener à bien votre projet ;
Développer les habiletés de leadership de vos chefs de projets implanter des outils de suivi pour livrer vos projets en respectant les coûts et les délais.
Qui devrait participer à ce programme de formation ?
Ce programme de formation spécialisé (voir la brochure détaillée) s’adresse aux personnes jouant le rôle de chefs de projets, ou membre d’équipe de projet, dans le cadre de projets de développement de produits et/ou de services.
Il est destiné à tous ceux qui désirent approfondir par l’action leurs connaissances en gestion de projets de développement de produits.
Une méthodologie ancrée dans l’action !
Ce programme unique de formation combine la présentation de notions théoriques et d’outils pratiques. Des exercices permettent d’appliquer les enseignements et d’utiliser les nouveaux outils dans le cadre d’un projet actuellement en cours dans votre entreprise. Entre les rencontres, vous devrez accomplir différentes tâches avec les membres de votre équipe de projet tout en bénéficiant d’une aide personnalisée de la part du formateur.
Vous avez suivi une formation PRINCE2, vous avez passé l’examen, vous êtes maintenant de retour à votre bureau, vous rouvrez le manuel de 350 pages, 19 chapitres et 26 documents …
Oui mais …. Par où commencer ?
… Simplifions les choses en 3 étapes !
1. Rédiger l’Exposé de Projet et faites-le approuver par votre exécutif
Comme son nom l’indique, l’Exposé de Projet est un document de synthèse.Il doit être facile à lire. Le manuel PRINCE2 suggère un modèle pour ce document : cependant, mieux vaut privilégier la lisibilité et la clarté plutôt que le formalisme et les détails.
L’Exposé doit contenir la structure organisationnelle du projet. Vous êtes le chef de projet, et vous avez besoin d’un Exécutif. C’est VITAL, le minimum vital. Sans Exécutif vous n’utilisez pas PRINCE2. L’Exécutif va assumer la responsabilité du projet. Vous allez exécuter en son nom le projet.
L’Exposé doit aussi contenir une description du produit du projet, votre livrable final. C’est important de le documenter, c’est ce qui va définir votre périmètre. Le manuel PRINCE2 nous dit que c’est un document séparé mais vous pouvez l’inclure comme un paragraphe de votre Exposé.
Afin de définir correctement votre produit du projet, vous devez comprendre qui est votre client ou utilisateur (celui-ci peut être un client interne ou externe). Vous devez discuter de vos livrables avec votre client, pour comprendre leur besoin. L’Exposé de Projet doit inclure les exigences qualité du client et les critères d’acceptation.
Une fois l’Exposé rédigé, l’Exécutif doit le valider, vous ne pouvez pas continuer sans cela.
2. Créer une Structure de Décomposition du Produit et en obtenir l’approbation
La structure de Décomposition du Produit (SDP) est un excellent moyen de comprendre ce qui doit être produit. Le SDP commence avec votre produit du projet, votre livrable final. Le SDP va vous donner plus de détails, 15 ou 20 livrables en tout.
Le moyen le plus simple de créer un SDP est de coller des post-it sur un tableau. Par ce biais il est facile de remodeler le SDP au fur et à mesure que les idées émergent. De manière idéale, faites-vous appuyer d’un collègue ou deux pour garantir une vision plus large. Une fois cela réalisé, convertissez les post-it en version électronique en utilisant un outil tel que Visio ou Powerpoint. C’est important de créer le SDP avant de commencer toute planification. Pour PRINCE2, le SDP est la première étape de planification.
Si vous utilisez un outil de planification, tel que MS Project ou même Excel, vous devez créer d’abord votre SDP et la faire approuver avant de commencer le travail avec ces outils. Votre PC doit être éteint !
Vous devez passer en revue la première version avec les acteurs clés : L’Exécutif, le client ou l’utilisateur et avec les chefs d’équipe qui vont produire la solution. Une fois approuvée vous pouvez créer le plan de projet autour des 15-20 livrables de votre SDP.
3. Créer un Cas d’Affaire en collaboration avec votre Exécutif.
Le cas d’affaire fourni la justification du projet. Il explique les ressources que le projet va utiliser et les compare avec les bénéfices escomptés. C’est un document important, cela dit, il doit être simple et court. Le problème avec le Cas d’Affaire est que l’on ne sait jamais quel niveau de détail est approprié. Votre Exécutif va vous guider sur ce point. N’ajoutez pas de détails superflus (si votre société n’a pas besoin d’exprimer les besoins en termes financiers, ne le faites pas).
Commencez avec un résumé de votre besoin en ressources, et les bénéfices escomptés – pour de nombreux projets, c’est suffisant.
Les ressources sont habituellement des personnes et/ou de l’argent. Vous devez comprendre quels types de ressources sont nécessaires. (Par exemple, vous avez besoins de développeurs et de testeurs et de l’argent pour acheter les équipements).
La justification se base sur les bénéfices – obtenez les informations sur les bénéfices avec votre Exécutif. Tous les deux, vous devez comprendre les types de bénéfices que votre projet va générer (par exemple, réduction des coûts de production, de maintenance).
Une fois que vous avez un résumé vous pouvez détailler davantage, seulement si nécessaire. Il faudra peut-être convertir les ressources et les bénéfices en termes financiers. Vous aurez besoin probablement d’un calendrier et aussi d’un calcul financier complexe tel que la valeur actualisée nette. En tous les cas, simplifiez toujours les choses, n’effectuez pas le travail si ce n’est pas nécessaire.
1,2,3…
En trois étapes simples, on a les fondements de notre DIP (Documentation d’Initialisation de Projet).
Les trois piliers clés du DIP sont : l’Exposé de Projet, le Plan de Projet et le Cas d’Affaire. Ces trois étapes nous permettent de créer ces trois piliers. Voici la manière de mettre en pratique les concepts de votre formation PRINCE2 en trois étapes simples.
Un chef de projet travaillait sur un petit projet, trois mois pour livrer une nouvelle partie de logiciel. Après environ deux semaines, le sponsor de projet a décidé d’ajouter quelques nouveaux besoins. Le chef de projet les a incorporé. Un peu plus tard, le sponsor a fait un peu plus de changements et a demandé un peu de nouvelle fonctionnalité. De nouveau, le chef de projet a dit que ce n’était pas un problème. Les changements ont été faits. Vers la fin des trois mois, le sponsor est allé chez le chef de projet se plaindre que le projet soit en retard sur le calendrier. Le chef de projet a essayé d’expliquer que tous les changements signifiaient qu’il n’y avait aucune possibilité que le logiciel puisse être achevé dans le délai original. Le sponsor n’était pas content et le chef de projet a été viré du projet parce qu’il était « trop lent ».
Cela vous semble familier ? J’espère que non ! La dérive de contenu est ce qui arrive quand les changements sont faits sur la portée d’un projet sans contrôle. Bien sûr, les changements arrivent tout le temps dans les projets et il est très rare qu’un projet livre au final exactement ce que l’on avait demandé au premier jour. Cependant, les changements sans contrôle signifient que le chef de projet a une très faible chance de rester en contrôle du travail sur le projet et manager efficacement le projet.
La dérive de contenu prend généralement la forme de nouveaux besoins qui sont ajoutés après que le projet ait commencé.
Typiquement ceux-ci ne sont pas correctement passés en revue et l’équipe projet est escomptée les livrer avec les mêmes ressources et dans le même temps que le périmètre original. D’autre part, vous pourriez finir avec un projet qui a des tas de changements dûment considérés et approuvés, mais qui ne finit jamais parce que, chaque fois vous pensez que vous avez fini, un nouveau besoin arrive dans votre boîte à lettre et vous devez faire davantage de changements.
Voici 5 façons d’empêcher la dérive de contenu d’endommager votre projet.
1. Documentez les besoins
L’unique et plus importante chose à faire sur votre projet lorsqu’il s’agit de dérive de contenu est de documenter vos besoins. Parlez à toutes les parties prenantes du projet et mettez au point exactement ce qu’elles veulent que le projet réalise. Documentez leurs besoins. Vous aurez à gérer quelques conflits – si une partie prenante veut que le nouveau site Web soit bleu et une autre partie prenante veut du vert, vous aurez besoin de quelqu’un pour arbitrer et rendre une décision finale. De plus, vous devriez prioriser certains des besoins car il peut ne pas être possible de les réaliser tous.
Cela peut prendre du temps de consulter toutes les parties prenantes et d’enregistrer tout ce qu’elles disent. Une fois que vous l’avez fait, capturez tous les besoins dans un document. Alors, vous pouvez ceci partager dans votre espace de stockage de fichiers en ligne pour que tout le monde puisse les consulter facilement.
2. Mettez en place un Processus de Contrôle des Changements
Image courtesy of stockimages / FreeDigitalPhotos.net
Votre documentation des besoins est le point de départ, mais que se passe-t-il quand quelqu’un veut changer quelque chose ? Il est peu réaliste de penser que rien ne changera. Ce que vous visez est un changement managé et contrôlé sur votre projet et pour cela vous avez besoin d’un processus de contrôle des changements.
Un processus de contrôle des changements est très simple. Votre logiciel de management de projet peut avoir la fonctionnalité de gérer des demandes de changement et vous pouvez alors l’utiliser. Essentiellement, quelqu’un suggère un changement, il est passé en revue, approuvé ou rejeté et si approuvé, incorporé ensuite dans le plan de projet.
La mise en place du processus pour votre projet signifie de vraiment réfléchir à qui va passer en revue et approuver les changements. Vous pourriez les revoir avec votre sponsor de projet ou lors d’une réunion d’équipe. Vous n’avez pas besoin de planifier une réunion formelle et récurrente de revue des changements à moins que vous ne pensiez en recevoir énormément et qu’il sera alors plus facile d’être assis avec vos collègues pour les passer en revue tous en même temps.
3. Créez un échéancier de projet qui soit très clair
Utilisez vos besoins pour créer une liste détaillée de tâches. L’échéancier de projet résulte de savoir ce que livrera votre projet, donc il devrait montrer tous les besoins et comment ils seront réalisés, sous forme de tâches et d’activités.
Vous pouvez établir des références croisées entre votre échéancier et votre documentation des besoins, juste être sûr que vous n’avez rien oublié.
4. Vérifiez la définition du contenu avec les parties prenantes
Grille des parties prenantes
Il est important aussi de vérifier que vous ayez correctement compris les besoins. Ce que vous pensez que veux le sponsor de projet pourrait en réalité ne pas correspondre exactement à ce qu’il a voulu dire. Souvent les gens se contredisent sans le réaliser, prenez le temps de retourner voir vos sponsors et de partager votre documentation de ses besoins avec eux. Vous pouvez aussi leur montrer votre échéancier de projet et vous assurer que tous les éléments qu’ils se seraient attendus à y voir y sont bien présents dans la liste des tâches.
Vous pouvez aussi faire ceci avec toutes les autres parties prenantes. Prévoyez un peu de temps avec chaque partie prenante et parlez leur précisément de ce que le projet va livrer. Montrez-leur le plan et donnez-leur la chance d’exprimer des remarques. Vous pourriez constater qu’ils changent d’avis, même à cette étape, mais il vaut mieux le savoir maintenant que poursuivre votre projet et constater dans deux ou trois mois qu’ils vous amènent des besoins différents.
Vous pouvez aussi utiliser ces discussions pour parler à votre sponsor et parties prenantes du processus de contrôle des changements. Expliquez comment vous gérerez des changements sur le projet et de quelle approbation vous aurez besoin de leur part pour les accepter. Ceci est un bon moment pour leur rappeler qu’ils peuvent avoir à peu près tout ce qu’ils veulent – s’ils sont préparés à payer pour cela et à autoriser le projet à prendre plus de temps comme ils incluent de nouveaux besoins !
5. Parlez à l’équipe projet
Si vos parties prenantes sont satisfaites, vous devriez vous assurer que votre équipe projet l’est aussi. Ils ont besoin de connaître le processus de contrôle des changements et comment il les impactera. Parfois les membres de l’équipe d’équipes projet voudront être vraiment serviables et ils accepteront de changer certaines choses sans utiliser le processus formel. Utilisez votre discussion avec eux pour expliquer qu’ils ne peuvent pas dire oui à un changement sans que ce changement ait été formellement approuvé. S’ils veulent aider une partie prenante, la meilleure chose à faire est d’expliquer le processus et offrir d’aider à documenter la demande de changement.
La dérive de contenu peut être un réel problème sur des projets, particulièrement quand l’équipe et les parties prenantes ne comprennent pas l’impact que les changements peuvent avoir sur les ressources, le budget et les délais. Heureusement, cela ne doit pas être un problème majeur si vous êtes clairs de la portée initiale du projet et managez soigneusement les demandes de changements pendant le cycle de vie de votre projet.
Relisez ce billet sur l’engagement des parties prenantes:
Vous avez suivi une formation PRINCE2, vous avez passé l’examen, vous êtes maintenant de retour à votre bureau, vous rouvrez le manuel de 350 pages, 19 chapitres et 26 documents …
Oui mais …. Par où commencer ?
… Simplifions les choses en 3 étapes !
1. Rédiger l’Exposé de Projet et faites-le approuver par votre exécutif
Comme son nom l’indique, l’Exposé de Projet est un document de synthèse.Il doit être facile à lire. Le manuel PRINCE2 suggère un modèle pour ce document : cependant, mieux vaut privilégier la lisibilité et la clarté plutôt que le formalisme et les détails.
L’Exposé doit contenir la structure organisationnelle du projet. Vous êtes le chef de projet, et vous avez besoin d’un Exécutif. C’est VITAL, le minimum vital. Sans Exécutif vous n’utilisez pas PRINCE2. L’Exécutif va assumer la responsabilité du projet. Vous allez exécuter en son nom le projet.
L’Exposé doit aussi contenir une description du produit du projet, votre livrable final. C’est important de le documenter, c’est ce qui va définir votre périmètre. Le manuel PRINCE2 nous dit que c’est un document séparé mais vous pouvez l’inclure comme un paragraphe de votre Exposé.
Afin de définir correctement votre produit du projet, vous devez comprendre qui est votre client ou utilisateur (celui-ci peut être un client interne ou externe). Vous devez discuter de vos livrables avec votre client, pour comprendre leur besoin. L’Exposé de Projet doit inclure les exigences qualité du client et les critères d’acceptation.
Une fois l’Exposé rédigé, l’Exécutif doit le valider, vous ne pouvez pas continuer sans cela.
2. Créer une Structure de Décomposition du Produit et en obtenir l’approbation
La structure de Décomposition du Produit (SDP) est un excellent moyen de comprendre ce qui doit être produit. Le SDP commence avec votre produit du projet, votre livrable final. Le SDP va vous donner plus de détails, 15 ou 20 livrables en tout.
Le moyen le plus simple de créer un SDP est de coller des post-it sur un tableau. Par ce biais il est facile de remodeler le SDP au fur et à mesure que les idées émergent. De manière idéale, faites-vous appuyer d’un collègue ou deux pour garantir une vision plus large. Une fois cela réalisé, convertissez les post-it en version électronique en utilisant un outil tel que Visio ou Powerpoint. C’est important de créer le SDP avant de commencer toute planification. Pour PRINCE2, le SDP est la première étape de planification.
Si vous utilisez un outil de planification, tel que MS Projet ou même Excel, vous devez créer d’abord votre SDP et la faire approuver avant de commencer le travail avec ces outils. Votre PC doit être éteint !
Vous devez passer en revue la première version avec les acteurs clés : L’Exécutif, le client ou l’utilisateur et avec les chefs d’équipe qui vont produire la solution. Une fois approuvée vous pouvez créer le plan de projet autour des 15-20 livrables de votre SDP.
3. Créer un Cas d’Affaire en collaboration avec votre Exécutif.
Le cas d’affaire fourni la justification du projet. Il explique les ressources que le projet va utiliser et les compare avec les bénéfices escomptés. C’est un document important, cela dit, il doit être simple et court. Le problème avec le Cas d’Affaire est que l’on ne sait jamais quel niveau de détail est approprié. Votre Exécutif va vous guider sur ce point. N’ajoutez pas de détails superflus (si votre société n’a pas besoin d’exprimer les besoins en termes financiers, ne le faites pas).
Commencez avec un résumé de votre besoin en ressources, et les bénéfices escomptés – pour de nombreux projets, c’est suffisant.
Les ressources sont habituellement des personnes et/ou de l’argent. Vous devez comprendre quels types de ressources sont nécessaires. (Par exemple, vous avez besoins de développeurs et de testeurs et de l’argent pour acheter les équipements).
La justification se base sur les bénéfices – obtenez les informations sur les bénéfices avec votre Exécutif. Tous les deux, vous devez comprendre les types de bénéfices que votre projet va générer (par exemple, réduction des coûts de production, de maintenance).
Une fois que vous avez un résumé vous pouvez détailler davantage, seulement si nécessaire. Il faudra peut-être convertir les ressources et les bénéfices en termes financiers. Vous aurez besoin probablement d’un calendrier et aussi d’un calcul financier complexe tel que la valeur actualisée nette. En tous les cas, simplifiez toujours les choses, n’effectuez pas le travail si ce n’est pas nécessaire.
1,2,3…
En trois étapes simples, on a les fondements de notre DIP (Documentation d’Initialisation de Projet).
Les trois piliers clés du DIP sont : l’Exposé de Projet, le Plan de Projet et le Cas d’Affaire. Ces trois étapes nous permettent de créer ces trois piliers. Voici la manière de mettre en pratique les concepts de votre formation PRINCE2 en trois étapes simples.
Une des premières activités d’un projet c’est le cadrage. L’objectif principal c’est de définir précisément une feuille de route, d’éclaircir et de partager une vision commune entre le chef de projet et son sponsor en lien avec la direction. Découvrez dans cette première « vidéo de cadrage projet » pourquoi et comment cadrer son projet.
Partenaire de DantotsuPM
Mais qu’appelle-t-on exactement le périmètre du projet?
Dans un projet, je dois connaître précisément ce qui m’est confié. Bien évidement, je vais expliciter ce dont je suis responsable. Mais il est aussi très pertinent d’identifier tout ce qui est nécessaire à la bonne réalisation du projet mais qui ne semble pas m’être confié. Découvrez dans cette vidéo comment circonscrire précisément le périmètre d’un projet.
partagez ce billet avec vos amis, collègues et relations professionnelles
La mentalité dominante dans le management et la finance dans les sociétés est aujourd’hui centrée sur l’efficacité, la productivité et les coûts. La préoccupation principale est de maximiser tous les actifs et capacités pour que rien ne reste assis, inoccupé. Ce que cela signifie vraiment est de garder les gens utilisés à 100 %.
Si la demande est là, cela a du sens de maximiser la production. Mais connaît-on vraiment la demande ?
Avec le développement piloté par les spécifications, il y a d’habitude l’attente implicite que toutes les fonctionnalités exigées soient exprimées. Et si toutes les fonctionnalités construites n’étaient pas utilisées avant longtemps ? Cela accroîtrait simplement l’Inventaire. Et si une proportion de ces fonctionnalités n’était jamais mise en œuvre par les utilisateurs ? Ce serait un gaspillage d’argent et de ressources.
Toutes les demandes ne sont pas égales. Toute chose n’est pas fonctionnalité. Il vaut mieux supprimer la demande qui ajoute un coût, mais peu de valeur. Quels sont les différents types de travail et quels sont leurs besoins ?
Trouver l’équilibre entre la capacité avec la demande signifie que quelques actifs resteront inoccupés: parfois certaines personnes se retrouveront avec un peu de temps libre entre leurs mains. Dans le domaine de la production, les coûts d’inoccupation sont généralement acceptés en échange d’une réduction de l’inventaire et des coûts de stockage et d’éviter la conséquence de devoir vendre la surproduction à prix réduits.
Le temps « mort » fournit un espace dont il devrait être fait bon usage. Toute personne avec du temps libre a une responsabilité de s’assurer que le coût de ce temps « mort » est récupéré par des améliorations sur l’ensemble de la valeur (incluant des améliorations de la façon de travailler et la suppression d’inefficacités) qui réduisent le coût de production et augmentent la qualité.
partagez ce billet avec vos amis, collègues et relations professionnelles
Dans la gestion de projet Agile, nous devons prioriser une liste de demandes pour la planification de version, d’itération et l’insertion de nouveaux besoins ou exigences. Mais il y a plusieurs techniques pour le faire.
Une des méthodes les plus populaires pour déterminer la priorité des demandes est l’approche dite « MoSCoW ». Cela signifie ‘ Must (Doit), Should (Devrait), Could (Pourrait), Won’t (ne fera pas). ‘ Le seul problème avec cette méthode est que d’habitude tout est un Must, ce qui ne permet pas une planification appropriée parce que les besoins ne sont pas nécessairement placés dans leur ordre de priorité.
Une autre méthode estle modèle de Kano, développé par le Professeur Noriaki Kano, qui s’efforce de satisfaire les exigences et de faire plaisir aux clients. Ce modèle dispose de quatre composants :
• Must haves (doit avoir) sont des éléments sans lesquels on ne peut livrer le produit.
• Dissatisfiers (générateurs d’insatisfaction) sont des choses que le produit ne doit pas inclure.
• Satisfiers (générateurs de satisfaction) incluent besoins pour lesquels plus vous en avez mieux le produit sera perçu. Comme un catalogue commercial dans lequel chaque fonctionnalité ajoute progressivement de la valeur.
• Delighters (générateurs de plaisir) amènent le produit plus loin que simplement répondre aux exigences vers l’augmentation de la satisfaction client et la recommandation par le client.
Plusieurs modèles de priorisation réunissent deux variables dans un tableau pondéré : fonctionnalités et clients. Chaque fonctionnalité est pondérée par sa valeur pour chaque client. La somme des poids multipliés par le score permet de voir quelles fonctionnalités sont en général les plus utiles pour un jeu de clients exigeants.
Quel que soit la technique utilisée, votre liste d’exigences de projet doit être triée de la plus grande à la plus faible valeur.
Quelles techniques utilisez-vous pour prioriser les besoins ?
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Marc Bonnemains du PMI Ile de France nous indique de nouveaux Webinars sur la gestion des changements.
Une série de webinars gratuits en anglais sur le management du changement donnés par le Change Management Learning Center. Ces webinars donnent lieu à des PDUs en catégorie 3 pour les certifiés PMI.
Je suis fatigué des chefs de projet qui se plaignent de la mauvaise qualité de la définition des exigences. La vérité est que personne ne devrait s’en étonner. Dans la recherche comme dans les désastres très visibles, nous entendons dire que des exigences incorrectes et la mauvaise gestion du contenu sont des raisons principales d’échec des projets. Si nous savons que c’est un problème commun de notre profession, pourquoi continuons-nous stupidement à répéter ce qui ne marche pas ? Je voudrais partager quelques suggestions pour nous empêcher de trébucher sur ces mêmes erreurs :
Abandonnez l’illusion d’obtenir des exigences complètes.
Il y a toujours une dépendance manquée, une partie prenante que nous n’avons pas interviewée, une nuance cachée, ou une chose que nous regretterons de n’avoir pas su. Ne tombez pas dans le piège de penser que davantage est toujours mieux ou vous ne commencerez jamais.
Supposez toujours que les besoins initiaux sont faux.
Parfois la définition du contenu est trop inclinée vers une partie prenante ou n’a pas été correctement examinée de près. Parfois la plus grande partie des exigences sont en réalité seulement des choses « agréables-à-avoir ». De nos jours, on s’attend à ce que le chef de projet ait le bon sens organisationnel et les compétences de facilitation pour arriver à la cause racine de ces problèmes. Pour vous assurer que vous donnez les bonnes priorités au bon moment, prenez la déclaration de portée initiale comme un point de départ, travaillez ensuite avec le sponsor pour l’affiner.
Acceptez que tout besoin change.
La culture de management de projet traditionnelle décrit le changement comme un mal nécessaire, comme les lois : si tout le monde faisait tout correctement, nous n’aurions pas besoin d’elles. Pour atténuer « le risque » lié au changement, nous mettons en place des processus de demande de changement intimidants et des pénalités financières. Mais que se passe-t-il si ce que vous avez développé pendant les deux dernières années n’est plus approprié pour votre marché ? Y-a-t-il un sens à continuer à faire payer votre sponsor pour ce qui est maintenant essentiellement un produit inutile ? Pas selon moi. Si nous acceptons que les exigences soient incomplètes et incorrectes, nous devons les modifier pour refléter la réalité. En effet, le corpus de connaissance en management de projet (PMBOK ®) énonce : “à cause du potentiel de changement, le plan de gestion de projet est itératif et passe par l’élaboration progressive tout au long du cycle de vie du projet.”
Simplifiez votre approche de gestion des modifications.
Les chefs de projet agiles embrassent explicitement la valeur de bien répondre aux changements et instituent une politique de projet en conséquence. Commencez par mettre en œuvre une structure de contrat qui supporte les changements autorisés plutôt que les pénalise. Au début de chaque itération, organisez une revue de haut niveau mais minutieuse des priorités de contenu. Si votre sponsor a des difficultés à déterminer les priorités, assistez-le en lui indiquant les différences. Une fois que les changements sont acceptés, redéfinissez les références de la valeur acquise au moins toutes les trois à quatre itérations pour qu’elles correspondent au dernier périmètre. Et pendant que vous y êtes, communiquez proactivement la dernière définition du contenu à toutes les parties prenantes.
Si vous trouvez systématiquement que la définition des exigences vous amènent des problèmes, faites quelque chose. C’est votre responsabilité de chef de projet que d’être adaptable aux besoins de votre sponsor. Arrêtez de prendre les exigences pour acquises et commencer à équiper votre sponsor pour qu’il fasse les bons choix de contenu.
partagez ce billet avec vos amis, collègues et relations professionnelles
5 Things You Must Know About Requirements Planning (1 PDU)
Requirements Planning adds incredible value to the requirements process. More than simply creating another “work breakdown structure” document, this is an opportunity to address risks proactively and gain better stakeholder participation. This session demonstrates how every component of a requirements plan adds value.
Learning Objectives
1. Illustrate the pitfalls of traditional approaches to Requirements Planning
2. Deliver guidelines for making Requirements Planning a value-add activity
3. Know what material must be present in a high quality requirements planning document
Harmonizing Agility & Discipline: Balancing Warring Methodologies and Achieving Success (1 PDU) This session demystifies the wide range of agile and more traditional requirements and development methodologies. The session looks at the strengths and weaknesses of each approach and gives prescriptive guidelines to requirements leadership looking to improve results by striking a better balance between agile and disciplined practices. This session refocused the agility versus discipline dialogue: it is not that these practices are mutually exclusive – the real issue is to look at your current circumstances and find the right balance to maximize success.
Learning Objectives
1. Look at the structure of agility and discipline-based methods
2. Provide guidelines for adding agile practices to traditional software development environments
3. Provide guidelines for reapplying traditional development practices to the agile software development environment
Managing Requirements Operational Excellence: A Framework for Accelerating Organizational Development (1 PDU) This session is for business analyst leadership and development executive looking to make long term, systematic improvement to their business analyst organization. IAG will draw from its project experience with over 700 customers to baseline organizations, assess the value of improvement, and determine the action plan for success.
Learning Objectives: 1. How do you assess the maturity of an analyst organization?
2. Where do you focus for improvement?
3. What implementation guidelines should be used to enhance success?
Predicting Project Outcome – 1 PDU
This is an advanced webinar for senior project managers and giving them the facts to predict the outcome of their project based on the quality of the business requirements process and deliverables. Findings are based on extensive research, and a predictive risk assessment model is presented. The presentation also shows actions that project managers can take to mitigate risk should requirements issues be found.
Optimizing Requirements Discovery – 1 PDU Why should it take months to determine project scope and gather requirements? Register now to look at the underlying problems that impede the collection of business requirements and make projects less successful. Within this session, participants get new data from IAG’s research that quantifies the cost of poor requirements and shows the impact on companies of a strong, repeatable process. Attendees will see some of the techniques IAG uses in our methodology and proven successful on over 1,000 engagements. Finally, making quantum organization improvement is our specialty and this session will review the levers of change that IAG focuses on to deliver excellent results.
Outsourcing Requirements Discovery – 1 PDU
This session is for project managers that sometimes need to contract externally for requirements discovery services in order to make their project a success. This session shares hard facts, case studies, and a wealth of experience in successful – and not so successful – contracting approaches for the senior project manager. This session covers engagement models that drive value, identifying red flags in the contracting or managing stages of working with vendors, and the targets for vendor performance Supercharging a project by accelerating the requirements discovery phase is a solid strategy – but how do you ensure the company will get solid business value from the activity?
Collect Requirements: Action Steps That Get Results – 2 PDU
This is a fast paced session for Project Managers, Analysts, and Development Leadership of all skill levels and experience to overview how to collect requirements efficiently. Why take the session: Project Managers need to know what PMBOK® Guide – Fourth Edition “Collect Requirements” has in expected outputs. Business Analysts need superior techniques for engaging stakeholders. Development Leadership wants to get transparency into the process of requirements, and know what value this brings to the organization. This session wraps these three critical objectives into an intense, two hour session.
Learning Objectives: 1. When should the requirements be defined? How and by whom?
2. How do I keep the clients on track and the requirements aligned with the agreed objectives?
3. What is the difference between a use case and a requirement?
7 Secrets to Defining Requirements for Package Software Selection – 2 PDU
This two hour on-line course will provide Business Analysts and Project Managers with essential techniques and specific guidelines for gathering and defining the right kind of requirements needed for inclusion in an RFP for the selection of a vendor for application software. In order for Business Analyst’s and Project Manager’s to perform effective and efficient vendor evaluation, the business requirements need to be appropriately defined and structured. If you have struggled strategies for commercial-off-the-shelf software acquisition, what level of detail is needed in an RFP, when and how to involve the vendors, what research is required, and what templates to use — then spend two hours with us to help you set the right path for success with your next COTS project.
Learning Objectives 1. How are the methods for defining requirements for a software product different than for custom developed solution?
2. How much detail is needed for an RFP? How do I know what to exclude and include?
3. How do we accommodate changing requirements? When do we hold vendor demonstrations?
6 Steps to Prioritizing Your Business Requirements – 2 PDU
This two-hour webinar for project managers and business analysts gets right to the point and covers the essential steps for prioritizing business requirements – a process based on industry best practices ranging from QFD, MoSCoW and others – and employing IAG’s experience and proven techniques for practical requirements prioritization. This webinar will explain why prioritization is important, when it is needed and when it isn’t, when it should be done, what different strategies could be used and what techniques work best. Participants will learn a practical process that is adaptable to various types of projects from large to small and a variety of environments from agile to waterfall. It will provide Project Managers and Business Analysts with a clear understanding of what they need to know, and what they need to do, to easily and effectively prioritize the product requirements for their next project.
Learning Objectives 1. The Most Effective Prioritization Strategies
2. Different Prioritization Techniques, Why Prioritize?, When to Prioritize Knowing , What to Prioritize
3. The Six Steps to Prioritizing Business Requirements
4. Key Requirements Prioritization Success Factors
5. Facilitating Requirements Prioritization Meetings, Rating Facilitation Methods
partagez ce billet avec vos amis, collègues et relations professionnelles
Soyez à court le chocolat et c’est la honte. Soyez à court d’oxygène et vous êtes foutus.
Préciser le rôle du chef de projets, en mode agile
Qui devrait participer à ce programme de formation ?
DantotsuPM.com 