articles, méthodes, partages d'expérience et rdv du management de projets et de l'agilité
The Scrum Framework
Lyssa Adkins qui se présente comme une coach de Coach Agile (les ScrumMasters par exemple), montre dans cette vidéo comment expliquer Scrum à quiconque en reprenant dans un graphique les principes clés de cette approche. Lyssa est l’auteur du livre Coaching Agile Teams.
The Wedding Cake
Elle va plus loin avec cette démonstration de comment expliquer très simplement les différences et les bénéfices qu’il y a à adopter une approche Agile.
http://kenschwaber.wordpress.com/2011/05/03/empiricism-the-act-of-making-decisions-based-on-what-is/
Par Ken Schwaber
L’empirisme est l’acte de prendre des décisions basé sur ce qui est. Scrum est un processus empirique, parfois décrit comme “l’art du possible.” Par cela, je veux dire que nous faisons du mieux nous pouvons avec ce que nous avons.
Un Propriétaire de Produit (« Product Owner ») planifie une version (« release ») basée sur toutes les informations actuellement disponibles. Il ou elle définisse les objectifs, les fonctionnalités et les capacités qui délivreront ces buts ainsi que le coût probable et la date de livraison. À partir de ce moment-là, le travail du Propriétaire de Produit est d’évaluer ce qui est possible vu les capacités de l’Équipe et de prendre les meilleures décisions pour atteindre l’objectif souhaité. Étant donné la nature de la technologie, des marchés, des besoins et des personnes, des compromis sont faits. Parfois le but ne peut pas être atteint pour un prix raisonnable. Parfois le but sera atteint, mais d’une manière différente de ce que le Propriétaire de Produit pensait initialement. C’est l’empirisme en pleine action.
L’Équipe (de développeurs) sur l’Équipe Scrum fait de même. Elle rencontre le Propriétaire de Produit et évalue ce que le Propriétaire de Produit voit comme les choses les plus importantes à faire ensuite. Si réalisées, celles-ci dirigeront le produit émergent dans la meilleure direction vers le but désiré. L’équipe choisit autant de choses qu’elle croit pouvoir en faire pendant le prochain Sprint. Le coût de l’équipe et la longueur de Sprint est fixe. Seule la quantité d’items du « Product Backlog » choisie peut varier. Le Propriétaire de Produit et l’Équipe définissent souvent un objectif pour le Sprint. C’est un sous-ensemble des objectifs de la version (« release »).
Quand l’équipe choisit des items lors d’une réunion de Planification de Sprint, elle s’engage à le faire pendant le Sprint.
Une définition « s’engager » est : « Se lier moralement par une promesse : Il s’est engagé à payer ses dettes dans les huit jours. » selon le Larousse. (ndlt)
Cela correspond à ma compréhension du mot s’engager, qui est une promesse, un engagement à un plan d’action.
Cependant, beaucoup d’équipes Scrum utilisent le mot « s’engager » comme si c’était « une garantie ». C’est un reste des méthodes en cascade, où une évaluation était un contrat. Cependant, cela résonne toujours dans les têtes de propriétaires de produit et des développeurs. J’ai trouvé équipes après équipes qui estiment qu’elles doivent tout faire pour respecter leur engagement. La victime est habituellement la qualité.
Je me demande si nous devrions échanger le mot « s’engager » pour celui de “prédire” ?Ceci pourrait donner la même impression que la présentatrice météo essayant de nous fournir les meilleures informations possibles. Elle fait avec que l’on connaît et avec la science de la météorologie. Elle ne fournit pas de garantie, mais quelque chose que nous pouvons utiliser pour prendre des décisions. Les prévisions sont également utilisées par les organisations de ventes. Peut-être cette clarification nous aidera-t-elle à comprendre qu’ « un engagement » dans Scrum est une promesse de faire de notre mieux avec ce que nous avons.
http://blog.castsoftware.com/technical-debt-no-penalty-for-early-payment/
Posté Par Jon sur le blog de Cast Software
Nous sommes une société de débiteurs. Nous nous endettons pour nos voitures, nos maisons, et grâce aux cartes de crédit nous nous endettons même pour l’épicerie et l’essence.
Dans le développement logiciel, comme dans la vie, avoir un peu de dette peut en réalité être une bonne chose pour faire progresser des choses plus critiques. Bien que dans des blogs précédents nous ayons défini la dette technique comme « le coût pour réparer des problèmes de qualité structurels d’une application qui, si laissés défectueux, pourraient mettre le business en danger », engager une petite et raisonnable somme de dette technique peut en réalité faire avancer le projet plus rapidement et faciliter l’atteinte de l’objectif d’avoir un logiciel exécutable. C’était la pensée de Ward Cunningham, le créateur du concept de dette technique.
Mais comme Derek Huether l’indique dans son blog de conseils technologiques pour le Dumas Lab à propos de la Dette technique : « Comme toute dette habituelle, vous vous trouverez tôt ou tard devant le besoin de la rembourser. »
Huether note aussi que tout comme une dette dans nos vies personnelles, si non remboursée, d’une façon ou d’une autre :
…elle reviendra pour vous hanter. Si votre bidouille d’une solution ne revient pas mordre l’équipe de développement, elle hantera probablement le bureau de support technique, l’équipe de support, ou quelqu’un d’autre en aval.
Il ajoute alors :
Comme toue dette, vous vous retrouvez devant le besoin de la rembourser tôt ou tard …, j’ai vu (et vois) ce que la dette technique peut faire à la vélocité d’une équipe. Elle les prive d’un temps précieux, après coup. L’équipe de développement achète l’idée que faire des choses de la mauvaise manière, qui peut sauver un peu de temps dans l’immédiat, vaut les risques et le coût total. C’est vraiment une vue à court terme du processus de réflexion. La dette technique ressemble à l’obtention d’un prêt d’un usurier qui lance les dés pour décider de votre taux d’intérêt. Aussi, si vous n’êtes pas obligés de prendre le risque, ne le prenez pas.
Mais la dette technique est-elle vraiment une proposition de type tout ou rien ?
Combien est assez ?Quand elle en vient à la Dette Technique, une société doit déterminer combien, si quoi que ce soit, devrait être investit pour y remédier. La meilleure façon de le faire est en donnant une valeur monétaire (en monétisant) la dette technique pour donner une valeur financière à la qualité structurelle de l’application. Cela permet de comparer les coûts informatiques aux pertes potentielles coté business en raison d’un échec qui n’était pas possible précédemment (avant de contracter cette dette).
Le but de monétiser la dette technique est de maintenir le nombre de violations de la qualité structurelle – ou ce qui est plus important, le coût de les réparer – bien en dessous du coût que la société encourrait si le logiciel devait être déployé et aboutir à un échec.
Pour déterminer le point de basculement des problèmes de qualité structurelle et du coût pour les réparer, une société devrait utiliser une plate-forme d’analyse et de mesure automatisée pour évaluer la qualité structurelle de leurs cinq applications les plus cruciales à la mission de l’entreprise. La façon dont chacune de ces applications est construite, leur qualité structurelle devrait être mesurée à chaque version majeure et une fois qu’elles fonctionnent, la qualité structurelle de l’application devrait être mesurée chaque trimestre.
La clé est de garder un œil vigilant sur le compteur des violations; contrôlez les changements et calculez la Dette Technique de l’application après chaque évaluation de qualité. Quand une valorisation monétaire de la dette technique a été vérifiée, elle peut être comparée à la valeur business pour déterminer combien de Dette Technique est trop et combien reste acceptable par rapport au retour marginal sur la valeur business. Pour établir une structure pour calculer la perte de valeur business en raison des violations de qualité structurelles, nous recommandons “The Business Value of Application Internal Quality” par Dr. Bill Curtis.
Une fois que ce point de basculement est déterminé, une société peut décider où et quand elle doit aborder les problèmes de qualité structurelle qui ont créé la dette technique.
La partie agréable de se débarrasser de dette technique est la même que pour la dette personnelle: cela évite le paiement de plein d’intérêts. Pourtant, il n’y a aucune pénalité à rembourser en avance… en fait, cela apporte une récompense significative grâce à un logiciel de meilleure qualité.
A l’occasion du sommet Gartner du mois dernier en Californie, le « Gartner PPM & IT Governance Summit » à San Diego, les analystes de ce groupe ont publié le « MarketScope for Project and Portfolio Management Applications » que vous pourrez lire dans son intégralité en cliquant sur ce lien.
Notre partenaire Microsoft y a obtenu la plus haute distinction « Strong Positive rating », validant les choix stratégiques de placer SharePoint au cœur de la solution intégrée en management de projet et portefeuille de projets que ce soit pour le workflow, la gestion de documents ou la collaboration.
Source: Gartner (June 2011)
Par Marc Biarnès, Escalation Engineer, CSS – EMEA Project Team, Microsoft France
Description de SP1: http://support.microsoft.com/kb/2460052/fr
Le Service Pack contient:
Le Cumulative Update (CU) de juin 2011 contient tous les correctifs jusqu’au mois de juin.
Il y a des packages indépendants pour les Service Packs (SP -> 60xx) et les Cumulative Updates (CU -> 61xx). Ils peuvent être installés dans n’importe quel ordre mais Microsoft recommande l’ordre suivant:
Unique exécution du PSConfig (sur chaque serveur), le n° de version est visible. Distribution par Windows Update manuelle pendant 90 jours puis distribution automatique.
1. Support Multi Navigateurs : Support de « Internet Explorer 9 in Internet Explorer 8 Standards Mode, » ainsi que le support de Google Chrome, Firefox et Safari.
2. Synchronisation des tâches : Avant SP1, la synchronisation était limitée aux tâches manuelles. Avec SP1, la synchronisation des tâches automatiques est supportée et le changement de dates est mis à jour dans Project Pro.
3. Support du « Timephased Tracking », le suivi des heures effectuées par période de temps, sur toutes les tâches, y compris les tâches manuelles pour lesquelles ce n’était pas le cas auparavant: Il est donc possible de reporter du temps dans My Tasks et Timesheets sur toutes les tâches. Cette nouvelle fonctionnalité est supportée par le client et le serveur et nécessite l’installation du SP1 sur le client ET sur le serveur. Attention, ne fonctionne pas si le Backward Compatibilty Mode (BCM) est activé.
4. Edition des projets contenant des tâches à Travail Fixe et Piloté par l’effort dans Project Web Access : Il est maintenant possible d’éditer des plans contenant des tâches Travail Fixe et Pilotées par l’Effort dans Project Web App
5. Auto Publication : Une nouvelle fonctionnalité qui facilitera la vie des chefs de projet, en particulier ceux qui gèrent de nombreux projets : La possibilité si on le souhaite de publier automatiquement les mises à jour de son projet par une règle similaire à celle permettant d’accepter automatiquement des feuilles de temps.
PMI revoit très régulièrement ses standards pour s’assurer qu’ils continuent de coller à la réalité du terrain et de s’enrichir des meilleures nouvelles pratiques. Pour autant, le standard des meilleures pratiques pour le découpage en tâches du projet ne change pas cette année suite à un examen détaillé par trois experts praticiens du management de projet.
écrit par Neil Stolovitsky de Genius Inside
Agile fait beaucoup de bruit actuellement dans les milieux de développement de logiciels. La méthode a été créée par des développeurs pour des développeurs. Son origine remonte à 10 ans lorsqu’un groupe de développeurs ont mis en place l’Agile Manifesto dans une station de ski dans l’Utah. Ce manifeste visait à établir pour les projets de développement de logiciels un système plus inclusif, démocratique et efficace. Il en a résulté plusieurs méthodologies Agile dont notamment Crystal Clear, Scrum et Extreme Programming, toutes créées afin de mettre en place des équipes de projet autonomes qui placent la responsabilité dans les mains de chaque personne qui touche le projet.
Ceci est une toute nouvelle approche de gestion des équipes de projet. Les groupes de développement de logiciels doivent être très prudents lorsqu’ils déploient Agile dans leur organisation, car les équipes sont en général habituées à être surveillées et guidées tout au long du projet. En réalité, il y a de nombreux points à considérer avant d’implémenter Agile afin d’être sûr que les changements proposés par Agile soient positifs et non négatifs par rapport au processus existant. Voici les cinq points les plus importants pour vous aider à déterminer si la méthode Agile est la bonne pour vos développeurs:
Une culture trop différente est l’une des raisons principales à l’échec d’un environnement de travail de gestion de projet. Les environnements Agile sont autonomes, ils font face aux clients et sont démocratiques par nature. Tous les groupes de développement cherchant à adopter Agile doivent avant tout se demander si ces principes sont en accord avec la culture et les valeurs de la société ? S’ils sont en complète opposition, les chances de réussite sont minimes. La dernière chose à faire est de démarrer du mauvais pied!
La plupart des environnements de travail en management de projet réussissent simplement avec une bonne adhésion du leadership. Même si la culture de la société est adéquate, Agile nécessite une adhésion complète depuis la base dès le départ. Chaque personne a un rôle à jouer: des clients aux développeurs, étant donné que chaque personne a sa part de responsabilité avec Agile.
Est-ce que votre société est prête pour un changement? Étant donné qu’Agile requiert un changement d’envergure, il est primordial qu’une stratégie de gestion du changement soit en place afin de minimiser les risques et d’assurer une transition en douceur entre l’ancienne et la nouvelle manière de faire les choses.
La méthodologie Agile nécessite une compréhension complète de sa philosophie et de son environnement de travail dès le début. Cette méthodologie nécessite la participation de tous les membres de l’équipe, il est important que chacun connaisse l’ensemble du processus ainsi que sa propre contribution. Toute autre approche risque de faire échouer son implémentation.
La base de l’efficacité des projets Agile est l’effort concerté de mise en place d’un système qui permette une collaboration efficace entre les parties prenantes internes et externes. Vous devez vous non seulement vous demander s’il existe dans votre société une stratégie de communication efficace, mais surtout vous devez être sûr que vos clients seront prêts à s’investir lourdement dans le développement de leurs projets.
Pour en savoir plus au sujet de la méthodologie Agile, regardez ce bref (6′) et récent web cast (ci-dessous en anglais) et livre blanc (en anglais également).
http://www.allaboutagile.com/10-good-reasons-to-do-agile-development/
by Kelly Waters
Voici 10 bonnes raisons d’appliquer les principes et pratiques de développement agiles …
1. RevenusLa nature itérative du développement Agile implique que des fonctionnalités sont livrées de façon incrémentale, ce qui permet de commencer à encaisser des revenus pendant que le produit continue d’être développé.
La recherche suggère qu’environ 80 % de tous les leaders du marché ont été les premiers à commercialiser sur ce marché. En sus d’un revenu plus élevé grâce à une livraison progressive, la philosophie de développement Agile supporte aussi la notion de sorties en avant-première et de versions régulières et les versions « perpétuellement bêta ».
Un principe clé de développement Agile est que les tests sont intégrés tout au long du cycle de vie. Ce qui permet une inspection régulière d’un produit fonctionnel en cours de développement. Cela permet au propriétaire de produit (le « product owner ») de faire des ajustements si nécessaire et donne à l’équipe de produit la primeur de tout problème de qualité.
Les principes de développement Agile encouragent la participation active des utilisateurs tout au long du développement du produit dans une approche collaborative très coopérative. Cela fournit une excellente visibilité aux principales parties prenantes, à la fois sur l’avancement du projet et sur le produit lui-même, ce qui aide à son tour à s’assurer que les attentes sont gérées efficacement.
De petites versions progressives donnent de la visibilité au « product owner » et à l’équipe produit pendant le développement, permettent d’identifier les problèmes au plus tôt et facilitent la réponse à ceux-ci. La visibilité claire dans le développement Agile aide à s’assurer que les décisions nécessaires peuvent être prises le plus tôt possible, pendant qu’il reste du temps pour apporter une différence substantielle sur le résultat.
Dans des projets de développement traditionnels, nous écrivons de grandes spécifications au préalable et disons ensuite aux responsables business combien il est coûteux de changer quoi que ce soit, particulièrement quant le projet avance. Dans la crainte de dérive du contenu et de projet interminable, nous résistons aux changements et faisons passer les personnes par un comité de contrôle des changements pour les réduire au minimum vital. Les principes de développement Agile sont différents. Dans le développement Agile, le changement est accepté. En fait, on s’y attend. Parce qu’une chose certaine dans la vie est le changement. Au lieu de cela la durée est fixe et les exigences apparaissent et se développent comme le produit est développé. Bien sûr, pour que cela fonctionne, il est impératif d’avoir des parties prenantes impliquées qui comprennent ce concept et prennent les décisions de compromis nécessaires, négociant le contenu existant pour un nouveau.
La susdite approche de durées fixes et besoins en évolution permet d’avoir un budget fixe. Le contenu du produit et ses fonctionnalités sont variables, plutôt que le coût.
8. Satisfaction du client/business La participation active d’un représentant des utilisateurs et/ou un propriétaire de produit (« product owner »), la forte visibilité du produit et de l’avancement et la flexibilité de changer quand le changement est nécessaire, créent un bien meilleur engagement du business et la satisfaction du client. C’est un bénéfice important qui peut créer des relations de travail beaucoup plus positives et durables.
Par-dessus tous les autres points, la capacité des besoins de développement Agile à émerger et à évoluer et la capacité d’embrasser le changement (avec le compromis approprié), fait que l’équipe construit le bon produit. Il est trop commun dans des projets plus traditionnels de livrer un projet « réussi » coté informatique et de constater que le produit n’est pas ce à quoi on s’attendait, dont on avait besoin ou que l’on espérait. Dans le développement Agile, l’accent est mis absolument sur la construction du bon produit.
L’engagement actif, la coopération et la collaboration font des équipes de développement agiles un endroit beaucoup plus agréable pour la plupart des personnes. Au lieu de grandes spécifications, nous discutons des besoins dans des ateliers. Au lieu des longs rapports d’avancement, nous collaborons autour d’un tableau des tâches, discutant du progrès. Au lieu des longs plans de projet et des Comités de Gestion de Changement, nous discutons de ce qui est juste pour le produit et le projet et le L’équipe est autorisée à prendre des décisions. Dans mon expérience, cela donne une approche beaucoup plus utile pour chacun. À son tour, cela aide à créer des équipes fortement motivées, à haute performance qui sont fortement coopératives.
Mais il y a des implications. Il n’existe rien de tel qu’un déjeuner à l’œil ! Et il n’y a aucune baguette magique pour le développement logiciel. Désolé, non, cela n’existe pas 🙂 En échange de tous ces avantages, vous obtenez moins de prévisibilité, le logiciel et les personnes restent complexes, vous ne pouvez plus blâmer quelqu’un d’autre si les choses ne se passent pas bien et cela exige généralement beaucoup plus d’engagement et d’effort de chaque personne impliquée – c’est-à-dire que la collaboration est encore plus importante.
Néanmoins, les bénéfices du développement Agile sont vraiment irrésistibles.
http://blogs.pmi.org/blog/voices_on_project_management/2011/04/prioritizing-agile-project-req.html
par Bill Krebs
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 est le 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 ?
SimulTrain est un simulateur de formation en Management de Projet. Pour former des pilotes, on utilise un simulateur de vol – et pour former les chefs de projet, on utilise un simulateur de projet! Plus d’information sur SimulTrain sur Wikipédia.
SimulTrain® est un outil multimédia avec lequel les participants apprennent à:
Structurer et planifier un projet
Piloter le déroulement d’un projet
Utiliser les outils de gestion de projet
En participant à l’une de ces sessions d’une demi-journée, vous apprendrez tout ce qui est nécessaire à la mise en place et à l’utilisation de SimulTrain dans le cadre de vos formations et ses possibilités d’utilisation dans le perfectionnement des chefs de projet.
Tout ce dont vous avez besoin pour y participer est un ordinateur portable, la session est offerte.
Prochaines sessions:
PS : Le nombre de places étant limité par session, merci de nous retourner au plus vite votre demande d’inscription !
Marc Bonnemains, Conseil, développement d’affaires à l’international, a compilé une liste fort utile de différentes méthodes utilisées dans différents contextes.
Une nouvelle vidéo avec Nathalie Hesters (chef de produit Microsoft Project en France) pour avoir une vision d’ensemble de l’offre Microsoft autour de la gestion de projet : Microsoft Project 2010 et Microsoft Project Server 2010. A voir sur le site Microsoft Showcase !
PMI a publié le document que vous obtiendrez en cliquant sur l’image ci-contre pour nous fournir davantage de détails sur la Certification Agile. Les inscriptions débutent en mai pour les premières sessions d’examen en Septembre.
Vous y découvrirez notamment que l’examen consistera en 100 questions dont la moitié sur les outils et techniques Agiles et la seconde partie sur les compétences et connaissances Agile.
Coté outils et techniques, les aspects suivants seront couverts: Communications, Estimations, Planification, Suivi et Amélioration continue, Analyse et Design, Qualité et Tests, Compétences relationnelles, Priorisation, Management des risques, mesures et indicateurs, anamyse de la valeur.
Les compétences et connaissances sont organisés en domaines qui sont eux mêmes triés par niveau d’importance sur les projets agiles.
PMI nous propose également quelques pointeurs vers des documents et publications utiles pour préparer cet examen.
Une page dédiée sur le site PMI contient de nombreuses réponses aux questions que vous vous posez peut-être sur Agile.
MS Project permet de planifier les tâches, de maximiser l’utilisation des ressources, d’assurer le suivi des projets pendant leur réalisation et le contrôle des coûts.
La version 2010 contient beaucoup de nouveautés extrêmement utiles pour les chefs de projet. Je n’en citerai que quelques unes car je ne suis pas un expert mais celles-ci me paraissent répondre à des besoins concrets du chef de projet :
Tous les webcasts des TechDays 2011 sont désormais disponibles sur Microsoft Showcase, site de Microsoft où l’on retrouve de plus en plus nombreuses vidéos.
En voici une vidéo d’1 heure qui expose comment implémenter rapidement et efficacement Project Server 2010 en utilisant les nouvelles possibilités de planification et de pilotage offertes par le client Web Project Web App. Avec un exemple concret de Xavier Moquinchez Bolloré Africa Logistics.
http://www.cio.com.au/article/380395/understanding_project_management_processes_tools_drive_success/
Configurez votre programme pour réussir en conciliant processus et outils du management de projet.
Gary Hamilton, Gareth Byatt et Jeff Hodgkinson (dans CIO)
Il y a beaucoup d’aspects qui entrent en jeu dans un management de projet et de programme réussi : dur labeur, expérience, bonne collaboration, processus et pratiques de travail robustes, avoir de bons outils avec lesquels travailler, adopter et démontrer de bons comportements … la liste pourrait continuer. Cet article se concentre sur deux aspects du management de projet et de programme : les processus et les outils que nous utilisons et pose la question : Qu’est-ce qui vient d’abord : le processus ou l’outil ?
Nous ne cherchons pas à discuter des mérites d’outils et de techniques de management de projets différents. Nous n’examinerons pas non plus les différences entre le management de programme et de projet. Nous avançons plutôt ce qui nous l’espérons seront des points stimulants pour votre considération.
Les processus pour le management de projet et de programme sont bien documentés et aisément disponibles aujourd’hui de la part d’instituts professionnels et d’organisations telles que le Project Management Institute (PMI) et l’International Project Management Association (IPMA), des instituts de diverses professions orientées projet, des livres et des papiers de recherche, des organisations de formation et des groupes internes (par exemple, le personnel travaillant dans des bureaux de management de programme et de projet), dans des organisations commerciales et dans des organismes à but non lucratif.
L’assurance d’une compréhension minutieuse de processus à suivre et de comment “les instancier” dans votre programme ou projet est cruciale à la configuration de votre programme ou projet pour la réussite. L’une des clés du succès est de s’assurer que les processus sont représentés dans ‘ la façon dont vous faites des choses … ’, que dans cet article nous appellerons des comportements et des actions.
Tout simplement:
Par exemple, avoir une compréhension solide des processus requis pour Créez un Plan de Management de projet (PMP) est fondamental pour que le PMP dépeigne précisément comment l’équipe délivrera le projet. Vous devez alors démontrer des comportements et prendre des actions pour le faire arriver. La même chose pourrait être dite du processus d’évaluation de projet et de contrôle des dépenses, du processus de planification, du processus d’approvisionnement, du processus qualité, le processus de management des risques et tous les autres aspects du management de programme et de projet.
Mais même si vous êtes totalement conscients des processus que vous devriez suivre et des comportements et actions requises, est-ce suffisant pour garantir le succès, ou cela laisse-t-il trop de champ d’interprétation ? Êtes-vous gênés si vous connaissez les processus à suivre, mais ne pouvez pas les suivre parce que vous n’avez pas les bons outils? Avez-vous besoin du niveau « de contrôle » qu’un outil approprié peut fournir ?
Considérez ce scénario : Vous êtes un chef de projet et venez d’embaucher un groupe de professionnels extérieurs à votre organisation pour exécuter certaines parties de votre projet. Ni vous ni d’autres membres de l’équipe n’avez le temps de leur montrer “la façon dont les choses se font par ici”, et les processus spécifiques vous attendez qu’ils suivent. Dans ce cas, suffit-il de leur demander d’adopter les processus décrits dans vos guides de procédures sans leur fournir les outils spécifiques qui donneront la direction ?
Bien qu’un outil puisse incarner de bons processus, on peut soutenir que ce sont les comportements et les actions des individus qui font la réelle différence, indépendamment de ou des outils qu’ils utilisent. De tels comportements sont le résultat d’une compréhension de comment exécuter certaines activités; on ne peut pas l’apprendre un outil.
Nous avons tous besoin et nous attendons à ce que de bons outils nous aident à faire notre travail. Que vous soyez un chef de projet professionnel dans un bureau qui utilise une multitude d’outils informatisés, ou un professionnel qui œuvre dans un environnement différent, vous ne pouvez pas donner votre meilleur sans les bons outils…ou bien le pouvez-vous ?
Il y a des années, le management de projet était effectué avec les outils plus manuellement intensifs que ceux utilisés de nos jours, mais c’étaient néanmoins des outils. De la même façon, les charpentiers ont compté sur les scies à main et utilisent maintenant une variété d’équipement électriques qui les aident à faire le travail plus rapidement et avec moins d’effort physique ; les designers ont utilisé des maquettes construites à la main en l’absence de logiciel spécialisé de simulation sur ordinateur.
Des outils de management de projets de divers niveaux de complexité abondent aujourd’hui. Certains se sont développés vers des systèmes complet pour manager le projet lui-même, alors que d’autres sont spécifiques pour des disciplines particulières. Beaucoup d’outils de management de projets ont été développés par les organisations puis affinés au fil des ans à l’aide du retour d’information et de l’avis de groupes d’usagers. Que ce soient des outils de planification, de gestion des ressources, d’estimation, de gestion de portée ou une combinaison de toutes ces facettes et bien d’autres, ils peuvent fournir une plate-forme solide (“des rails”, si vous préférez) pour contrôler les projets.
Par exemple, considérez la planification. Les outils de planification informatisés d’aujourd’hui sont très puissants et permettent des vues consolidées en temps réel aux bornes d’un unique projet à une vue d’ensemble d’un portefeuille de projets sur une échelle mondiale.
Les outils peuvent sans aucun doute fournir une structure à notre travail. Tant qu’ils sont appropriés à la tâche et ont conçu supporter le processus, ils nous aident à devenir plus efficaces. Et c’est une des clés de l’utilisation d’outils. Nous devons utiliser le bon outil pour le travail à réaliser : ce devrait être une plate-forme pour atteindre l’efficacité et être utilisé convenablement et correctement suite à une formation appropriée.
Revisitons notre scénario de projet : Dans cette situation, vous prenez un groupe de professionnels extérieur à votre organisation pour exécuter certaines sections du projet, mais vous n’avez pas le temps pour leur montrer “la façon dont les choses se font par ici” et les processus spécifiques que vous attendez qu’ils suivent. Êtes-vous toujours confiants que si vous leur donnez les outils à utiliser sans attention aux processus à suivre, ils adhéreront aux processus de la façon dont vous le prévoyez ?
Nous croyons fermement que les processus et outils doivent travailler en harmonie les uns avec les autres et que le processus devrait déterminer comment l’outil doit être utilisé. Les outils varient dans leur niveau de sophistication et ils peuvent certainement aider votre efficacité et niveau de consistance et de contrôle si (1) ils sont bien appropriés pour la tâche à réaliser et (2) ils sont utilisés correctement. Vous ne pouvez pas utiliser un outil efficacement sans connaître les processus qu’il dirige ou vous demande de suivre. Le besoin de connaître le « pourquoi » et le « comment » utiliser un outil est la raison pour laquelle vous avez d’abord besoin d’une compréhension du processus (et des comportements). Sans « le pourquoi » et « le comment », nous ne comprenons pas la signification réelle derrière la tâche à réaliser.
Les chefs de programme et de projet doivent combiner la connaissance des processus, incarnés dans des comportements et des actions, avec les outils pour effectuer leur travail. Comprenez vos processus d’abord et utilisez ensuite l’outil disponible le plus approprié pour entreprendre le processus.
Si vous avez un avis sur cet article, nous voudrions vraiment recevoir des commentaires de votre part. Envoyez-les s’il vous plaît par courrier électronique à Contactus@pmoracles.com.
Mettez un peu de management de risques dans votre moteur « projet »un billet de Marc Burlereaux
Membre Fondateur du PMI® Pôle des Pays de Savoie
Certifié PMI-RMP® Risk Management Professional
Un sondage organisé par l’association PMI® (Project Management Institute) a indiqué que 54% des projets finissent soit dans les temps prévus, soit selon le budget convenu, mais rarement les 2 en même temps…
Nous parlons ici de projets au sens large. Si l’on se limite aux seuls projets informatiques qui peuvent être plus « risqués » que d’autres types de projets reposant sur un savoir-faire deux fois millénaire comme ceux de la construction, les statistiques peuvent être différentes … Remarquez qu’une de mes connaissances me disait que lors de la construction de sa maison le budget initial avait été largement dépassé par les nombreux avenants , ce qui devrait rappeler des souvenirs douloureux à nombre d’entre vous …
Ce sondage PMI® indique également que la méthodologie la plus utilisée par les organisations « à hautes performances » en management de projets est le management des risques … à hauteur de 88% des réponses …
Livrer en temps et heure un produit qui correspond aux attentes du client selon le budget et la qualité convenue : est-ce une utopie ?
J’entends déjà certains d’entre vous « que va nous vendre ce beau parleur ? » Et aussi : « d’abord ce n’est pas mon problème, je ne suis pas à la tête d’une multinationale qui se dote d’outils sophistiqués pour gérer de nombreux projets ! »
Reprenons l’exemple de la construction de la maison : ne pensez-vous pas rétrospectivement qu’un « mini » management des risques aurait pu éviter quelques déboires ?
Certains me rétorqueront : «Mais j’ai déjà un responsable sécurité et logistique qui gère les polices d’assurance, le risque incendie avec la commission de sécurité et autres catastrophes naturelles, alors quoi d’autre ? »
C’est bien, mais ce n’est pas le même sujet. S’il est important de gérer le risque au niveau de l’entreprise, il est aussi important de sensibiliser les équipes projet au management du risque : que ce soit pour un projet informatique, pour le lancement d’un produit, pour le réaménagement de vos locaux, l’installation d’une succursale à l’étranger, la volonté d’exporter en Chine, …. Je ferai à ce sujet une double remarque : les risques « entreprise » sont à prendre en considération dans les risques projets et les risques projets peuvent avoir un impact de taille sur l’activité de l’entreprise : un projet informatique ayant pour objectif de remplacer le cœur de votre système d’information qui échoue le jour du démarrage a un impact vital pour la poursuite de vos activités, si une solution de secours n’a pas été prévue. Il est même conseillé de consolider les risques projets au niveau de l’entreprise pour une maîtrise et une prévention globales de leurs impacts.
PMI-RMP®, PMI® are registered mark of Project Management Institute, Inc.
La prise de conscience est déjà une première étape !
Ensuite, former une partie de son personnel, en ayant par exemple un « champion du risque dans le management des projets » qui portera la bonne parole. Se faire assister de manière ponctuelle peut aussi être une solution pour lancer ou consolider la démarche de management des risques dans les projets.
Enfin en tant que responsable, supporter, promouvoir/soutenir cette approche de manière pragmatique afin de s’assurer du succès de la démarche.
Quels sont les étapes principales à suivre ?Commençons par la définition du risque « un évènement incertain qui s’il arrive a un impact positif ou négatif sur les objectifs du projet ».
Je commence à dessein par le risque engendrant un impact positif ou « opportunité » : c’est très courant d’oublier cet aspect, ou alors on le fait de manière implicite. Mais le fait de commencer par lister avec l’équipe les opportunités potentielles du projet, qui par nature sont incertaines, permettra de mettre en place des actions qui favoriseront l’émergence de ces opportunités. Par exemple, cela pourrait être l’opportunité d’utiliser une nouvelle forge logicielle* dans le domaine du développement logiciel qui économisera du temps en phase de codage et de tests ou alors, de trouver d’autres clients intéressés par l’outil en cours de développement pour augmenter le retour sur investissement.
- identification (quels sont les risques ?)
- qualification des risques (définir « l’impact » et la « probabilité » de chaque risque et leur priorité)
Cette étape est vitale car elle permet de :
Si l’entreprise a déjà effectué cette démarche pour d’autres projets, il suffira de l’ajuster au projet concerné. Sinon, la personne en charge du projet aura un rôle de pionnier et devra définir beaucoup de choses. Je conseille à cette personne de suivre une formation ou de s’adjoindre l’appui d’un consultant en management de projets.
Pour l’illustrer je vais utiliser la règle des 3 C :
Lors de la phase d’identification :
Adresser les risques les plus prioritaires
- Éliminer le risque en décidant, par exemple de ne pas livrer un des composants d’un produit dont le développement est trop risqué,
- Réduire le risque en ayant, par exemple un personnel polyvalent pour faire face à des défections,
- Transférer le risque en s’assurant ou en sous-traitant, par exemple à une autre entreprise qui possède le savoir-faire
- Exploiter l’opportunité, en allouant par exemple plus de ressources expertes sur le projet et ainsi améliorer la qualité du produit livré,
- Partager l’opportunité, par exemple en développant une relation d’affaires avec un partenaire déjà implanté dans le pays que vous visez
- Améliorer l’opportunité, par exemple en créant des conditions favorables à la réussite de votre projet
Un bon plan de réponse d’un risque devrait contenir
- Les actions convenues à l’avance
- Le calendrier de ces actions
- La personne en charge de dérouler et contrôler le plan d’action
- Le plan de secours si les effets de l’action ne sont pas concluants
- Les risques résiduels, risques qui ne seront pas éliminés par le plan d’action
- Le ou les éléments déclencheurs
- Les échéances de revue du risque
Revoir les points positifs sur lesquels capitaliser pour un usage futurVoici quelques éléments qui, je l’espère, vous sensibiliseront au management du risque et vous permettront d’envisager les actions au sein de votre organisation pour les intégrer à votre management de projets et ainsi favoriser leur réussite. En effet, la gestion des risques n’est pas l’apanage des constructions gigantesques (Tours et barrages), de l’exploitation des centrales nucléaires et Laboratoires de haute sécurité classés P4, des avions très gros porteurs (800 passagers) ou de la prévention du terrorisme …
*Forge logicielle : système de gestion de développement collaboratif de logiciel. L’objectif d’une forge est de permettre à plusieurs développeurs de participer ensemble au développement d’un ou plusieurs logiciels, le plus souvent à travers le réseau Internet (source Wikipédia)
Tous les webcasts des TechDays 2011 sont désormais disponibles sur Microsoft Showcase, site de Microsoft où l’on retrouve de plus en plus nombreuses vidéos.
En voici une vidéo de presque 1 heure qui présente les possibilités de Project Server 2010 en matière de gestion de portefeuille, planification et pilotage des projets…
La définition des « bonnes » estimations sur un projet est un savant mélange d’expérience, d’échanges entre experts, de comparaison par analogies, de calculs… Le Planning Poker est l’un des outils de la méthode Scrum qui permet à une équipe lors d’une réunion de planification de donner des estimations pour le développement d’une fonctionnalité.
Lors de la réunion, le product owner (directeur de produit), qui représente comme toujours le client, définit les priorités de développement des nouvelles fonctionnalités du produit logiciel. L’équipe projet doit donner des estimations d’efforts au product owner afin que celui-ci comprenne ce que va coûter chaque nouvelle fonctionnalité. Et c’est là qu’intervient le Planning Poker. Pour jouer au planning poker, l’équipe doit donc avoir la liste de fonctionnalités à livrer (le product backlog) et un jeu de cartes de planning poker.
Dans ce jeu de carte, au lieu de porter des valeurs entre le 2 et l’as, les cartes portent des valeurs qui sont plus pertinentes à l’évaluation de durée de tâches. Typiquement ces valeurs sont : 0, ½, 1, 2, 3, 5, 10, 20, 50, 100. Ces valeurs correspondent au nombre de jours qu’une fonctionnalité donnée prendrait à être développée.
La session de planning poker est habituellement facilitée par un modérateur qui est souvent le ScrumMaster ou bien le coach Agile de l’équipe, les participants sont donc le « product owner » et l’équipe de développement.
1. Le modérateur lit la description de l’histoire utilisateur (« user story ») ou fonctionnalité que l’équipe doit estimer. Le product owner peut fournir des clarifications sur la fonctionnalité. Chaque expert est doté d’un jeu de cartes.
2. Chaque expert choisit une carte dans son jeu qui correspond à son estimation initiale de l’effort de développement. Chaque expert pose sa carte à l’envers sur la table pour ne pas influencer les autres experts.
3. Quand toutes les évaluations sont sur la table, les cartes sont retournées.
4. S’il y a une palette très large entre les estimations, les experts qui ont suggéré les plus fortes et plus basses évaluations fournissent le raisonnement qui les a amené à ces valeurs.
5. Une fois que la discussion sur la palette d’estimations a été conduite, les étapes 2 à 4 sont répétées jusqu’à ce qu’un consensus soit atteint.
L’avantage principal du planning poker est d’encourager une discussion ouverte sur les estimations. Cela aide l’équipe à atteindre une proposition plus précise au lieu de compter sur l’avis d’un membre de l’équipe plus influent ou plus vocal que les autres. Cela permet aussi à l’équipe de bénéficier de l’expérience de tous les membres de l’équipe.
Les cartes de planning poker peuvent être créées à partir de zéro. Ce lien vous permettra d’imprimer vos propres cartes de planning poker: http://www.sprintplanning.com/planningpoker_cards_1.gif et celui-ci de jouer en ligne: Http://www.planningpoker.com/
Voici une brève vidéo qui explique comment est née cette méthode.
Merci à Microsoft France de nous avoir indiqué ce fort utile guide de prise en main de MS Project 2010.
Pour vos premiers, seconds, troisièmes pas…
Avec ce guide référence, tout débutant saura, vidéos à l’appui, comment:
DantotsuPM.com 
