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.
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 :
Utiliser le nouveau ruban contextuel pour trouver plus facilement toutes les commandes
Créer un plan initial « top-down » sans dates calculées par l’outil, donc, de manière totalement manuelle et de ne passer que plus tard (ou jamais éventuellement) à un mode de calcul automatisé.
Créer un plan initial par simple copier/coller
Ajouter des tâches à travers l’interface graphique: créer, positionner, indiquer les dépendances…
Afficher et modifier le plan de charge des ressources. Une vue graphique de la planification d’équipe qui permet de voir facilement les points de surcharge et de mieux répartir le travail par un cliquer-déposer entre ressources du projet.
Gagner un temps précieux avec le nouvel affichage chronologique qui permet une communication simplifiée et plus facile avec les parties prenantes avec un copier-coller vers PowerPoint par exemple pour gagner du temps de préparation des comités de pilotage et/ou de revues client.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
L’argumentation pour les processus d’abord, les outils ensuite
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:
‘Les comportements‘ peuvent être vus à comme la façon dont les personnes dans une équipe projet se conduisent elles-mêmes pendant le cours du programme/projet.
‘Les actions‘ peuvent être vues comme les activités physiques et les interactions que l’équipe projet entreprend et manage pendant le cours du programme/projet.
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.
L’argumentation pour les outils d’abord, les processus ensuite
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 ?
Conclusion
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.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
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 …
Et si nous nous intéressions au management des risques pour améliorer les résultats des projets ?
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 ?
Comme par exemple :
un meilleur examen des références et du bilan de votre constructeur
une réflexion approfondie sur les risques induits par les solutions novatrices (dans mon cas personnel j’ai choisi une solution de chauffage novatrice en 1992, la géothermie au fréon … gaz qui troue la couche d’ozone …)
l’anticipation d’une solution de secours en cas de déficience d’un de vos artisans
la prévision d’une réserve financière pour les … nombreux … avenants (je recommande de particulièrement faire attention à l’électricité et les luminaires …) pour ne pas se retrouver à faire le tour de la famille pour boucher les trous.
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.
Que faire alors ?
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.
Examinons maintenant les différents processus du management des risques :
planification du management du risque, en définissant notamment la méthode et les définitions
communication autour du management du risque, peut-être le point le plus important
analyse des risques :
identification (quels sont les risques ?)
qualification des risques (définir « l’impact » et la « probabilité » de chaque risque et leur priorité)
préparation des plans de secours ou de contingence, y compris des budgets de réserve
suivi des risques tout au long du projet (mettre à jour de manière continue la liste des risques et leurs priorités (de nouveaux risques peuvent surgir comme d’autres peuvent disparaître), et être capable de présenter la liste des risques prioritaires : leurs impacts et les plans de contingence
clôture de la démarche (tirer les leçons apprises en vue de l’amélioration continue).
Voici quelques conseils qui me paraissent essentiels :
1. Planification :
Cette étape est vitale car elle permet de :
définir la méthode à appliquer et surtout l’adapter à la taille de l’entreprise et du projet,
formaliser les définitions de base pour une compréhension commune à tous,
définir le suivi des risques et les canaux de communication.
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.
2. Communication :
Pour l’illustrer je vais utiliser la règle des 3 C :
Communiquer : en vendant à l’équipe et aux parties prenantes (client, sponsor, partenaires…) le management des risques et ses plus-values dès le début du projet
Communiquer : en s’assurant que tout au long du projet de nouveaux risques émergent et documenter les actions prises suite à ces risques qui se sont transformés en problèmes réels; le management du risque doit faire partie du suivi hebdomadaire du projet
Communiquer : en veillant à une communication pertinente et ciblée à la structure hiérarchique sur l’évolution des risques et de leur prise en compte
3. L’analyse :
Lors de la phase d’identification :
S’assurer de la bonne formulation du risque : la cause (fait ou condition) de déclenchement du risque (incertain sinon c’est déjà un problème) ayant un effet (résultat potentiel qui peut être positif ou négatif)
Réunir les bons interlocuteurs pour réfléchir aux risques potentiels et notamment les équipes opérationnelles Réfléchir aux catégories de risque peut permettre de ne pas en oublier … mais attention à ne pas se limiter aux catégories existantes sous peine de limiter la créativité
Lors de l’analyse des risques :
Choisir une échelle de 1 à 10 pour qualifier l’impact et la probabilité des risques
Chaque risque aura ainsi un poids = probabilité x impact qui permettra ainsi de les prioriser afin de déterminer ensuite une action pour les plus prioritaires et de garder un œil sur les autres risques moins prioritaires sans les adresser directement
Ne pas confondre impact et probabilité et les évaluer de manière séparée. Si l’impact d’un risque (ou son effet) est élevé cela ne veut pas forcément dire que la probabilité qu’il se réalise soit élevée. Dans le cas de la tempête Xynthia, si les conséquences furent dramatiques (fort impact), par contre la probabilité de la conjonction de plusieurs risques était faible car il est rare de réunir de telles causes : la violence de la tempête et la surcote de 1m50 dues à trois facteurs, de forts coefficients de marée, l’influence du creusement dépressionnaire, agissant comme un « aspirateur » soulevant l’océan, et l’effet des vents de surface poussant la houle vers le littoral. Le poids de ce risque par sa gravité, même si la probabilité était faible, aurait nécessité la préparation d’un plan de contingence plus énergique, comme l’évacuation préventive des villes de La Faute sur mer et la Tranche.
Définir l’élément déclencheur qui annonce la matérialisation du risque
4. La planification des réponses à apporter si le risque se réalise (plans de contingence)
Adresser les risques les plus prioritaires
Établir des réponses de manière active afin de minimiser les impacts des menaces ou risques négatifs sur les objectifs du projet
É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
Penser aussi aux opportunités, les risques qui engendrent un impact positif
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
Si le coût de la réponse envisagée pour réduire ou éliminer un risque est plus élevé que l’impact estimé, cette réponse doit-elle être retenue ou doit-on accepter le risque ? La réponse sera souvent non.
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
Prévoir un budget de réserve pour les risques non anticipés
5. Le suivi :
Mettre le management des risques à l’agenda de chaque revue de l’avancement du projet
Mettre à jour la liste des risques en intégrant les nouveaux risques et en réévaluant les risques existants
Examiner les évènements déclencheurs des risques non encore réalisés
Décider la mise en place d’une réponse si un évènement déclencheur se manifeste
Surveiller les effets d’une réponse à un risque
Présenter au management la liste des 3 ou 5 risques majeurs
6. La clôture :
Revoir les points positifs sur lesquels capitaliser pour un usage futur
Lister les points d’amélioration à rectifier
Déterminer la plus-value du management des risques dans la réussite du projet
Voici 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)
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
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…
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
Quel est le processus ?
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.
Quel est l’avantage principal ?
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.
Convaincre votre directeur financier (Chief Financial Officer: CFO) et autres cadres sup de votre société d’utiliser Scrum est en réalité très simple, dans la théorie. Essayez cette stratégie la prochaine fois vous devez aider des exécutifs à comprendre pourquoi Scrum est un processus important et utile pour le développement logiciel.
Selon mon expérience, les experts financiers et les directions sont très attentifs à savoir ce qui arrivera si de certaines situations se produisent et veulent souvent simuler des scénarios dans leur stratégie de management des risques.
La meilleure approche dans cette situation est d’exposer la valeur business que vous livrerez si le projet devait s’arrêter en cours d’exécution.
Il y a plusieurs raisons pour lesquelles des projets de développement de logiciel sont arrêtés avant leur date de fin :
sévères compressions budgétaires
changement de priorités de projet,
la société a été rachetée
le budget approuvé n’est pas suffisant pour couvrir le périmètre complet du projet
En justifiant au management pourquoi utiliser utiliser Scrum il y a quelques années, nous avons posé cette question à la direction : Et si le projet devait être arrêté à environ 60 % de son effort ou calendrier ?
Le projet W a un modèle de réalisation et une dépense typique par phase :
10 % du temps/effort concernent la préparation et la définition du projet
25 % du temps/effort sont passés sur une analyse minutieuse du livrable logiciel
40 % du temps/effort sont passés sur le développement et les tests de système
20 % du temps/effort concernent les tests d’intégration et de recette ainsi que les corrections de bogue
5 % du temps/effort sont requis pour mettre le logiciel en production et le lancer avec les clients.
Comme vous pouvez voir, si on ordonne à l’équipe d’arrêter le développement à 60 % du parcours dans ce processus nous serons en réalité en plein milieu de l’écriture de code et de l’exécution de quelques tests système. Dans ce scénario, « la valeur » que le projet W délivre à la société est en fait un tas de documents d’analyse et un morceau de logiciel non testé.
Maintenant jetons un coup d’œil au modèle de dépense du Projet S, fonctionnant en mode Scrum:
10 % du temps/effort concernent la préparation et la définition du projet
85 % du temps/effort sont passés à analyser, développer et tester des incréments de fonctionnalités qui sont livrés itérativement dans des « sprints » bihebdomadaires
5 % du temps est nécessaire pour clôturer correctement le projet
Si le Projet S doit s’arrêter à 60 % en temps ou en effort dépensé, l’équipe aura déjà complété une bonne quantité de sprints et délivré un certain logiciel utilisable. Dans ce scénario, le projet S délivre une valeur réelle et des fonctionnalités utilisables (probablement environ 40 % à 50 % du produit total) au client.
Dans l’entretien avec la direction, nous avons utilisé un graphique sur la valeur acquise pour mieux illustrer notre point. Il inclut les suppositions suivantes :
Le démarrage et la définition d’un projet / produit correspondent à 0 % de la valeur totale
La documentation d’analyse et de conception représente 15 % de la valeur totale
Le code source avec les tests unitaires système correspondent à 35 % de la valeur totale
Le logiciel complètement testé et packagé représente 50 % de la valeur totale
Notre directeur financier et les autres cadres supérieurs ont décidé de commencer à utiliser Scrum pour nos développements de nouveaux produits parce qu’ils croient fermement que, d’une perspective de management des risques de la société, il vaut mieux utiliser Scrum qu’un développement par phase.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Si je devais identifier un seul outil/méthode/processus qu’il faut maîtriser parfaitement pour les chefs de projet, ce serait la structure de découpage du projet (WBS). Encore, je suis toujours stupéfié que dans certains des ateliers de travail poussés que je conduis sur la gestion de projet très peu de praticiens comprennent ce qu’est un WBS et comment développer un bon WBS qui aidera dans la planification de projet.
Heureusement, cette semaine j’enseigne « les essentiels du management de projet » donc mes attentes du savoir des participants sur le WBS sont assez faibles. C’est l’un des sujets que j’essaye de ne pas couvrir à toute vitesse, même si cela signifie que je déborde le temps qui lui est imparti dans l’agenda de l’atelier. L’endroit où je commence d’habitude est par la définition standard du WBS selon le PMBOK, qui expose :
“A deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project.”
Dans la communauté de management de projet il y a deux vues du développement de WBS. Un groupe se concentre sur l’identification des tâches qui sont nécessaires à accomplir sur le projet. Ce que cela signifie est qu’ils aiment identifier tous « les verbes » associés au projet. Dans ce cas, l’argument est qu’en identifiant les activités, on est capable de produire l’échéancier à partir du WBS. Dans certains outils de planification, il y a même une option pour produire une vue imagée de l’échéancier comme un WBS.
Il y a un autre groupe qui est concentré sur l’identification de tous les livrables qui doivent être produits par l’équipe projet. Ce que cela signifie est qu’ils identifient tous « les noms » associés au projet. Je suis un partisan de cette dernière vue. En travaillant sur la définition de tous les livrables, nous sommes capables de produire une liste des éléments à fournir par le projet. L’identification des tâches, l’évaluation et la planification sont donnent en effet des activités qui suivent mais à mon avis ne font pas partie du développement du WBS.
Voici quelques bons trucs qui m’ont servi bien dans le développement du WBS
Concentrez-vous le quoi pas le comment. ”Qu’essayons-nous de faire, pas comment ?”
Le WBS est une activité d’équipe, il devrait impliquer les parties prenantes du projet, pas seulement le chef de projet.
Donnez l’occasion à l’équipe de « remuer ses méninges » (brainstorm) en utilisant des post-it pour qu’ils puissent travailler tant de haut en bas que de bas en haut. Cela permettra de prendre en compte de multiples styles de travail. Ceux qui aiment commencer par la vue d’ensemble et ceux qui aiment les détails peuvent être satisfaits de cette réflexion en commun d’une façon qui les met à l’aise.
“Les mauvaises idées” devraient être encouragées pendant le remue-méninge et prises en compte lors de regroupements de livrables plus tard. L’avantage d’identifier un livrable qui est en dehors du périmètre projet est que cela peut être parqué sur une feuille séparée et documenté plus tard en tant que tel.
Assurez-vous de documenter les suppositions faites par l’équipe et d’utiliser ensuite ces suppositions comme une entrée potentielle dans l’identification des risques.
Ne vous contraignez pas à essayer de fournir les éléments dans l’ordre, cela viendra plus tard.
Assurez-vous que l’équipe documente les livrables internes et externes. Chez IBM nous utilisions le terme « produit de travail » pour des livrables internes pour les distinguer des livrables qui entrent dans un énoncé des travaux (statement of work).
Capturez les deux types de livrables. Beaucoup d’équipes oublient souvent qu’une une charte de projet et un plan projet sont en réalité des livrables qui devraient apparaître dans le WBS.
Utilisez le développement du WBS comme une opportunité de construction d’équipe en rassemblant les membres du projet et en accélérant les étapes de développement d’équipe.
Rappelez-vous la règle de 80 heures par lot de travail. À un bas niveau dans le WBS, on trouve les lots de travail. Ces lots de travail sont des livrables composés de tâches dont la somme devrait atteindre environ 80 heures d’effort.
Les bénéfices et utilisations du WBS sont multiples.
En identifiant la portée totale du projet par une décomposition par livrables, le WBS aide l’équipe de projet à réaliser les choses suivantes :
Comprendre ce qui est « à l’intérieur » et ce qui est « à l’extérieur » du périmètre du projet. Ce qui n’est pas listé, est en dehors. Ce processus peut permettre l’équipe de projet de documenter qu’un livrable donné est à l’extérieur du périmètre.
Envisagez les secteurs potentiels de risque, en vous servant des suppositions documentées.
Construisez une fondation pour développer une référence de base solide de projet et chaque lot de travail peut être utilisé pour identifier des tâches principales selon règle des 80 heures.
Communiquez avec des parties prenantes sur les besoins potentiels qui pourraient être demandés en croisant exigences et livrables.
Établissez une responsabilité claire pour les lots de travail et assignez des propriétaires/champions.
Il y a beaucoup d’autres trucs et bénéfices pour le WBS, tels que le système de codage qui peut être utilisé ou comment se servir du WBS pendant la phase d’exécution et dans le processus de contrôle. Même si chacun de ceux-ci est une considération importante, mon focus pour ce billet a été en utilisation du WBS comme un robuste point d’ancrage pour l’équipe pendant le processus de planification.
Je conclurai en soulignant qu’un bon WBS peut en effet être un facteur différenciant entre un projet réussi et un échec. Ceux qui ne sont pas familiers avec le WBS ou ne savent pas comment le créer doivent passer du temps à parcourir le PMBOK Guide et autres livres qui contiennent les appropriées.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Combien de fois vous est-il arrivé que la date prévue de démarrage soit reportée une fois, puis encore une autre fois avant de réellement pouvoir commencer?
Quand la date de début du projet change, vous pouvez très simplement mettre à jour la date de début du projet au niveau des informations projet et beaucoup de dates seront mises à jour automatiquement mais pas toutes (ex: dates butoirs, contraintes, tâche avec du travail déjà réalisé). Si vous voulez que ces dernières bougent également, aller sur « Move Project ».
L’avantage de « Move Project » est que tout sur le projet est déplacé en respectant le décalage par rapport à la date originale de début. Par exemple, dans ce projet la tâche b à une date butoir 5 jours après le démarrage du projet et tâche c a une contrainte de débuter 2 jours après le démarrage du projet (le 3 janvier 2011 : 1/3/11).
Maintenant, je sélectionne « Move Project » pour déplacer la date de démarrage du projet au 12 janvier 2011 (1/12/11).
Et tout dans l’échéancier est mis à jour respecte les mêmes délais par rapport à la date de démarrage du projet qu’auparavant. La tâche b a une date butoir 5 jours après le démarrage du projet et la tâche c a la contrainte de débuter 2 jours après le démarrage du projet.
Dans MS Project 2007 et versions précédentes, vous pouvez actionner cette fonctionnalité à partir de l’ « Analysis toolbar », ajuster les dates mais avec quelques limitations: les dates butoir et les tâches qui ne sont à 0% de complétude ne bougent pas.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Une Structure de Découpage du Projet (Work Breakdown Structure : WBS) dans le management de projet et l’ingénierie de systèmes, est un outil utilisé pour définir et grouper les lots de travail individuels d’un projet d’une manière qui aide à organiser et définir le contenu du travail total du projet. Un élément de structure découpage du projet peut être un produit, des données, un service, ou n’importe quelle combinaison. Un WBS fournit aussi la structure nécessaire pour l’évaluation de coût détaillée et le contrôle avec des conseils pour le développement et le contrôle de l’échéancier. De plus le WBS est un outil dynamique et peut être révisé et mis à jour autant que nécessaire par le chef de projet.
Un des principes de conception de Structure de Découpage du Projet les plus importants est appelé la Règle des 100 %. Cette Règle établit que le WBS inclut 100 % du travail défini dans le périmètre du projet et capture tous les livrables – internes, externes, provisoires – en termes de travail à réaliser, y compris le management de projet. La règle des 100 % est un des principes les plus importants guidant le développement, la décomposition et l’évaluation du WBS. La règle s’applique à tous les niveaux de la hiérarchie : la somme du travail au niveau « des enfants » d’une tâche doit égaler 100 % du travail de la tâche « parent » et le WBS ne devrait pas inclure de travail externe au périmètre réel du projet, c’est-à-dire qu’il ne peut pas inclure plus de 100 % du travail. En même temps, il ne peut pas en contenir seulement 95 %. Il doit contenir 100 % du travail. Cela s’applique au niveau de l’activité. Le travail représenté par les activités de chaque lot de travail doit s’élever à 100 % du travail nécessaire pour compléter le lot de travail.
La 4ème Édition du guide PMBOK déclare que créer le WBS est le processus de subdiviser des livrables de projet et le travail de projet en des composants plus petits, plus faciles à manager. Le WBS est une décomposition hiérarchique orientée à réaliser par l’équipe projet pour accomplir les objectifs du projet et créer les produits requis, avec à chaque niveau plus bas du WBS la représentation d’une définition de plus en plus détaillée du travail du projet. Le WBS organise et définit le contenu total du projet et représente le travail indiqué dans le document approuvé de déclaration de portée du projet. Le travail planifié est contenu au niveau le plus bas WBS des composants, qui sont appelés des lots de travail. Un lot de travail peut être planifié, estimé en coûts, surveillé et contrôlé. Dans le contexte du WBS, le travail se réfère aux livrables de travail ou aux produits qui sont le résultat de l’effort et pas à l’effort lui-même.
Lisez en davantage sur le WBS dans le PMBOK en commençant par la section 5.3.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
At TechEd this year, Christophe Fiessenger and Jan Kalis, technical product managers, presented an overview of MS Project 2010, Project Server and also how these products integrate with the reporting and collaboration capabilities of Sharepoint 2010 and of Microsoft Exchange.
To speed up your one hour video experience: the first 26′ are focused on MS Project, before moving at that time to Project Server. At 42’from start you’ll get further explanations on the integration capabilities for reporting, collaboration, time-sheeting and « statusing ». And, there is a short demo of the integration between project with MS Exchange at 50′ into the video which is something quite a few of us were requesting since a long time.
There are many more videos and slides from sessions with the same speakers for different audiences and different aspects of MS Project and Project Server 2010.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Les partenaires et clients Microsoft présents à Barcelone ont témoigné sur la valeur du Management de Portefeuille de Projet (PPM) et tous en arrivent à la même conclusion: PPM apporte réellement de la valeur au business.
Selon le Campana and Schott Group, PPM apporte de la valeur de 3 façons différentes :
1. Il réduit les dépassement de délais (de 37% à 15%)
2. Il réduit les dépassement de budget (de 25% à 11%)
3. Il augmente le pourcentage de projet qui apporte une vraie valeur économique à l’entreprise
Les meilleures entreprises qui utilisent le PPM le font non seulement pour standardiser les processus et les règles mais aussi pour être en position de réviser souvent leurs priorités si nécessaires en fonction des conditions business, ce qui leur donne un réel avantage compétitif.
Il faut remarquer que PPM siginifie des choses différentes selon les personnes et souvent amène à des implémentation un peu différentes qui amènent toutes de la valeur:
Implémenter un processus de priorisation des projets
Prioriser les projets et simuler la valeur de différents scénarios pour prendre la meilleure décision
Optimiser l’utilisation des ressources de l’entreprise
UMT Consulting Group mentionna que, de leur point de vue, PPM facilite aussi les 3Cs du management de la demande: Centraliser, Contrôler et Cataloguer. Cela fournit à la société la capacité de saisir les coûts estimés et bénéfices escomptés sur la durée du projet de manière pluri-annuelle si nécessaire.
Le fondateur de PM Consulting Services, Vladimir Ivanov, utilises aussi PPM pour accepter et planifier les demandes de changement sur des projets existants. Cela lui permet de centraliser ces demandes et de les mettre en visibilité de toutes les parties prenantes.
L’après midi, nous avons écouté le passionnant témoignage de Stéphane Perrin deVolvo IT qui a récemment déployé Project Server 2010. Selon lui, les raisons qui motivent le choix de l’outil de Enterprise Portfolio Management sont multiples.
3 furent clés dans son cas : La couverture fonctionnelle, la facilité d’utilisation de l’outil et la capacité à s’adapter à la croissance de la solution.
Compte tenu du nombre important de projets gérés en parallèle et des mutilples portefeuilles managés pour les divers clients de son service transverse d’informatique globale, ses avis furent bien écoutés de tous. Il nous parla en particulier des différents types de PPM que les sociétés ou dans son cas les Business Units de Volvo peuvent désirer. Quand ses clients lui disent: « nous voulons un PPM », il essaie de faire la distinction entre ceux qui veulent un PPM operationnel versus un PPM stratégique . Le PPM opérationnel se rapproche du tableau de bord pour contrôler les projets en cours alors que le PPM Stratégique implique des processus de gouvernance et d’optimisation de portefeuille de projets. Donc, avant de se lancer dans une implémentation complète de PPM, vérifier ce que veut réellement votre service ou société…
Nous avons aussi pu bénéficier de son approche coté formation des PMs à PPM. Il a choisi de ne donner qu’une journée et demi de formation initiale pour acquérir les principes de bases. Puis, il fait accompagner les PMs pendant une journée entière dans leur travail quotidien avec l’outil par un PM plus expérimenté avec Project Server.
« Commencez petit et soyez très clair sur l’objectif » fut le conseil final que j’ai retenu de Kudelski group cet après-midi.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
The Microsoft partners and customers testimonials on the value of Project Portfolio Management were all leading to this same conclusion: PPM does really add value to the business.
According to the Campana and Schott Group, PPM adds value in 3 major ways:
1. It reduces time overrun (37% to 15%)
2. It reduces budget overrun (25% to 11%)
3. It increases the share of projects that really add economic value to the business
Top performers in PPM use it not only to standardize processes and rules but also to be in position to re-prioritize and review projects often as business conditions evolve and this is a key advantage for them over their competitors.
It is to be noted that PPM means different things to different people and often drives slightly different implementations while all add value:
Implementing a workflow for project prioritization
Prioritizing projects and simulating the value of different scenarios to make the best decision
Optimizing the use of resources
UMT Consulting Group mentioned that in their view PPM also facilitates the 3 Cs of demand management: Centralize, Control and Catalog. It provides the company with the ability to capture estimated costs and expected benefits over the course of the entire project over multiple years if necessary.
PM Consulting Services founder, Vladimir Ivanov, also uses PPM to accept and schedule change requests to existing projects in order to centralize and make these very visible to all involved with the project.
During the afternoon, we had the striking testimonial of Stéphane Perrin of Volvo IT who has recently deployed Project Server 2010. For him, the reasons for deciding an Enterprise Portfolio Management tool can be multiple.
3 were key to his choice of the Project Server tool: Required functionalities coverage, quality/ease of the user interface and scalability of the solution.
Running many projects in parallel and managing several projects portfolios for the various customers of the transversal and global IT function, his advices were well listened to. He notably spoke about the different types of PPM that companies or in his case business units within the company may need. When his customers tel him « we want a PPM », he tries to make the distinction between those who want an operational PPM versus a strategic PPM. The operational PPM is mainly a dashboard to control projects execution while the strategic one involves processes and governance for project portfolio optimization. So, before launching a full blown PPM implementation, check out what your company of B.U. really wants…
We also benefited from his insight on the training aspect. The approach he has retained for new PMs coming on board the PPM solution is a day and a half course to get the basic concepts followed by one the job coaching for 1 day with an experiences PM to help with the real day to day work the PM will need to perform on the new tool set.
« Start small and be very clear on the objective » was the final advice I retained from Kudelski group this afternoon.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Arpan Shah, director of product management for Project, a lancé l’événement ce matin. Arpan a commencé par un bref rappel des événements qui ont pavé la route du management de projet sur les 100 dernières années. Depuis la conception des Gantt Charts vers 1910, au lancement de PMI dans les années 60 et de Prince2 dans les années 70… En parallèle à cette évolution du management de projet, nous avons vu grandir et se multiplier les outils pour supporter cette nouvelle discipline: au départ des applications sur PC destinées aux chefs de projet, et de nos jours des suites totalement intégrées en support du management de portefeuilles de projets. Donc, avec la plus grande maturité des organisations en matière de management de projet, les outils ont évolués d’une position de support aux « seuls » chefs de projet à apporter un réel bénéfice à l’ensemble des acteurs du projet: Managers de programmes, de portefeuilles de projet, directions, sponsors, membres de l’équipe, clients, fournisseurs…
Je retiendrais de l’intervention suivante qui fut donnée par Ludovic Hauduc, Programme Management for the work management products chez Microsoft, 3 principes fondateurs de Project et Project Server 2010: Une interface simple et intuitive, l’unification de Projet et portfolio management en un serveur unique et une plate-forme extensible sur laquelle partenaires et clients peuvent bâtir.
1. Une interface utilisateur simple et intuitive: « Après tout, le premier compétiteur de MS Project est Excel ! » commença Ludovic. De nombreuses améliorations apportées à l’interface utilisateurs de Project 2010 proviennent d’un simple concept qui pourrait s’appeler « en coulisses ». Le moteur MS Project est en effet dans cette nouvelle version du produit placé en retrait pour laisser au chef de projet la direction des opérations. Quand le chef de projet à besoin de la puissance du moteur MS Project, il ou elle lui fait appel à la demande plutôt que de se le voir imposer en permanence. Deuxième principe: « Sharepoint Server est au cœur de Project 2010, en fait, Project Server 2010 est une application Sharepoint et les développements réalisés pour Project Server enrichissent également Sharepoint » poursuivit Ludovic. La nouvelle interface web pour éditer les projets est devenue aussi riche que le client « lourd » et est devenu un élément clé du déploiement dans les entreprises car cela permet à de nombreuses parties prenantes d’accéder directement aux fonctions dont ils ont besoin: notamment donner le statut d’une tâche et reporter le temps passé et le reste à faire.
2. l’unification de Projet et portfolio management en un serveur unique. Le serveur unifié permet de créer de manière flexible de nouveaux projets avec un workflow d’approbation intégré pour mettre en place la nécessaire gouvernance, analyse de portefeuille projet et son optimisation. L’objectif a été d’ouvrir project server à davantage de personnes dans l’organisation que les seuls PMs: exécutifs, membres d’équipes projet, sponsors, partenaires…
3. une plate-forme extensible sur laquelle bâtir: Avec des fonctionnalités telles que les connecteurs qui permettent aux partenaires et équipes techniques internes d’ajouter des fonctionnalités sans toucher au cœur de project server.
La matinée s’est poursuivie avec des démonstrations des nouveautés phares des versions 2010 de ces outils puis des témoignages de partenaires Microsoft.
Une partie des démonstrations qui m’a particulièrement intéressé parlait de la capacité de priorisation des projets par rapport à 7 critères business proposés en standard dans Project Server. Et, la possibilité de jouer des scénarios différents sur le jeu de projets retenus pour 1. rentrer dans une enveloppe budgétaire qui vous serait imposée et 2. faire ceci en connaissance de cause et en maximisant le retour sur investissement global du portefeuille de projets.
Partenaire de DantotsuPM
<a href= »https://dantotsupm.com/wp-content/uploads/2010/11/dsc00049.jpg »><img class= »alignright size-medium wp-image-3801″ title= »DSC00049″ src= »https://dantotsupm.com/wp-content/uploads/2010/11/dsc00049.jpg?w=300″ alt= » » width= »300″ height= »225″ /></a><strong>Arpan Shah</strong>, director of product management for Project kicked off the event this morning. Arpan welcomed us with a brief reminder of the events that paved the way towards project management as we know it Today over the past 100 years. From the initial thoughts around Gantt charts in 1910, to PMI lauch in the 60s and Prince2 in the 70s… In parallel to this evolution, we also saw the growth of tools to support this new discipline: initially standalone SW applications for project managers, and nowadays fully integrated projects portfolio management.So, together with the increase of the maturity of Project Management in organizations, tools evolved from a position of supporting « only » the PM to benefiting all projects stakeholders: Programme managers, portfolio managers, executives, sponsors, team members, customers, suppliers…
<div>
I retained from the following presentation delivered by <strong>Ludovic Hauduc</strong>, Programme Management for the work management products at Microsoft, 3 key drivers that were behind Project and Project Server 2010: A simple and intuitive user interface, Unified Project and Portfolio Management within a single server product and an extensible platform for partners to build upon.
<strong>1. Simple and Intuitive User Interface:</strong> « after all, the first competitor of MS Project is MS Excel ! » started Ludovic Auduc. Many of the improvements brought to the user interface of Project 2010 come from a concept that could be called « back stage ». The MS Project engine is indeed with this new version taking the back seat and letting the PM do more if not all of the driving. When the PM needs the power of the scheduling engine of MS project, he/she will get it upon demand without having it forced on him/her. « Sharepoint Server is at the heart of Project 2010, in fact, Project Server 2010 is a Sharepoint application and developments done for Project are also enriching Sharepoint » continued Ludovic. The new web interface for Project editing has become as rich as the client version and is an asset for global deployment of functions widely used by many team memebers on projet: statusing and timesheeting.
<strong>2. Unified Project and Portfolio Management</strong> within a single server product. The unified server enables flexible project capture and initiation with customizable workflows to implement the required governance, portfolio analysis and portfolio optimization. The goal has been to open up project server to many more people in the organization that PMs: executives, team members, sponsors, partners…
<strong>3. an extensible platform for partners to build upon</strong>: With features such as connectors to enable partners to add functionality on top of Project and Project Server.
The morning continued with demos of some striking features of the so called <em> »twentyten »</em> 2010 versions of the toolset and partners testimonials.
Arpan Shah, director of product management for Project kicked off the event this morning. Arpan welcomed us with a brief reminder of the events that paved the way towards project management as we know it Today over the past 100 years. From the initial thoughts around Gantt charts in 1910, to PMI lauch in the 60s and Prince2 in the 70s… In parallel to this evolution, we also saw the growth of tools to support this new discipline: initially standalone SW applications for project managers, and nowadays fully integrated projects portfolio management.So, together with the increase of the maturity of Project Management in organizations, tools evolved from a position of supporting « only » the PM to benefiting all projects stakeholders: Programme managers, portfolio managers, executives, sponsors, team members, customers, suppliers…
I retained from the following presentation delivered by Ludovic Hauduc, Programme Management for the work management products at Microsoft, 3 key drivers that were behind Project and Project Server 2010: A simple and intuitive user interface, Unified Project and Portfolio Management within a single server product and an extensible platform for partners to build upon.
1. Simple and Intuitive User Interface: « after all, the first competitor of MS Project is MS Excel ! » started Ludovic Auduc. Many of the improvements brought to the user interface of Project 2010 come from a concept that could be called « back stage ». The MS Project engine is indeed with this new version taking the back seat and letting the PM do more if not all of the driving. When the PM needs the power of the scheduling engine of MS project, he/she will get it upon demand without having it forced on him/her. « Sharepoint Server is at the heart of Project 2010, in fact, Project Server 2010 is a Sharepoint application and developments done for Project are also enriching Sharepoint » continued Ludovic. The new web interface for Project editing has become as rich as the client version and is an asset for global deployment of functions widely used by many team memebers on projet: statusing and timesheeting.
2. Unified Project and Portfolio Management within a single server product. The unified server enables flexible project capture and initiation with customizable workflows to implement the required governance, portfolio analysis and portfolio optimization. The goal has been to open up project server to many more people in the organization that PMs: executives, team members, sponsors, partners…
3. an extensible platform for partners to build upon: With features such as connectors to enable partners to add functionality on top of Project and Project Server.
The morning continued with demos of some striking features of the so called « twentyten » 2010 versions of the toolset and partners testimonials.
A part of the demo that I found very interesting was around the prioritization of a portfolio of projects based on 7 drivers proposed out of the box on project server. And the ability to play what if scenarios to 1. match your budget constraints and 2. do this while maximizing the overall ROI of the portfolio.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Si vous êtes séparé par des mètres ou des kilomètres de vos clients, équipe ou bureau, voici quelques outils qui pourraient vous aider à combler toute distance et adresser ce défi.
Basecamp – une manière ordonnée de gérer des projets et de collaborer avec votre équipe et clients en ligne et par téléphone (prix indiqué de $24/mois).
DropMind-, outil interactif en ligne de « mind mapping » et de collaboration pour que les utilisateurs développent des plans, améliorent la communication et résolvent des problèmes. Interagit avec Basecamp, MS Project, et tout autre logiciel. A partir de £10.
Wisdomap – « mind mapping » sur le WEB pour organiser l’information, gérer des projets, fournir des présentations et intègrer des médias. Les utilisateurs Premium peuvent faire de la collaboration en temps réel. Gratuit, puis £10/utilisateur pour les fonctionnalités additionnelles telles que le temps réel.
Vyew – Application Web de collaboration qui permet à des utilisateurs de se réunir et de présenter aussi bien que créer et travailler ensemble sur le contenu. Le service de partage de bureau inclut une partie des outils de l’excellent tableau blanc. Gratuit, puis $36.95/mois pour les fonctionnalités supplémentaires telles qu’une plus grande capacité.
Dabbleboard – la collaboration en ligne sur un tableau blanc qui intéressera ceux qui réalisent des plannings, font une séance de brainstorming, présentent sur un tableau blanc. Les fonctionnalités incluent une bibliothèque publique pratique où vous pouvez copier des schémas que d’autres ont réalisés. Gratuit, puis $8/mois pour les fonctionnalités additionnelles tels que l’illimité sur les schémas privés ou les réunions et le cryptage. Voir également le leur produit AlmostMeet (bêta) pour des réunions collaboratives qui permettent la messagerie instantanée ainsi que le partage de documents et d’images.
VPMi – affiché comme traitant toute la vie du projet, programme, ou portefeuille et système de gestion des ressources. Ses fonctionnalités incluent des feuilles de présence et des utilitaires de gestion de document. Les prix disponibles sont $10/mois et $30/mois selon les différents niveaux d’accès.
DeskAway – logiciel collaboratif à la demande (« on demand ») sur le Web d’organisations, gestion et suivi de projets. Gratuit avec des fonctionnalités limitées telles que trois projets actifs et cinq utilisateurs et puis une gamme de forfaits à partir de $10/mois.
Teamwork Project Manager – logiciel en ligne de gestion d’équipe et de projets qui aide chacun impliqué dans un projet à travailler ensemble en ligne. Une option gratuite qui monte à £12/mois ou plus pour différents forfaits.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Les Gantt Charts sont très efficaces pour comprendre le progrès et statut du projet. Mais ils sont lourds côté planification. Ils donnent peu de compréhension de ce qui se passe. Un « burn down chart » est d’autre part bon pour comprendre le progrès du projet et où en sont les livrables.
Un « burn down chart » est la représentation graphique du travail qui reste à faire par rapport au temps. Le travail en attente (ou backlog) est souvent présenté sur l’axe vertical, avec le temps en horizontal. C’est-à-dire c’est un graphe d’exécution du travail en attente (du reste à faire). C’est utile pour prévoir quand tout le travail sera terminé.
Fabrication d’un « burn down chart » sous Excel
Étape 1 : Arrangez les données pour faire un « burn down chart »
Pour faire un « burn down chart », vous devez avoir 2 jeux de données. Le calendrier des tâches réellement exécutées et celui des tâches planifiées. Comme avec la plupart des graphiques, nous devons arranger les données. Je montre 3 colonnes supplémentaires que j’ai calculées pour réaliser le graphique « burn down chart ». Vous pouvez facilement deviner les formules.
Étape 2 : Faites un bon vieux graphique à lignes
Choisissez juste les séries « Balance Planned » et « Balance Actual » et créez un graphique à lignes. Utilisez la première colonne (des jours) dans la susdite table pour les labels sur l’axe des abscisses.
Étape 3 : Ajoutez les valeurs complétées quotidiennes (Daily Completed) pour compléter le « burn down chart »
Choisissez la colonne « Daily Completed » et ajoutez-la au graphique. Une fois ajoutée, changez le type de graphique pour cette série à histogramme (lisez comment combiner 2 types de graphiques en un : combine 2 different chart types in one)
Étape 4 : Ajustez le formatage et des couleurs
Ajouter ou supprimer les lignes de grille selon vos désirs. Ajustez des couleurs et la légende si nécessaire.
Téléchargez le modèle “burn down chart”
Click here [.zip version here] to download the excel burn down chart template. Use it in your latest project status report and tell me what your team thinks about it.
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.
DantotsuPM.com 
