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)
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Le premier billet lu sur PMI Community m’a rappelé combien il est difficile pour tout un chacun de changer ses habitudes et comportements. Le second sur Zen Habits propose une approche pour créer une nouvelle habitude. Et la petite vidéo d’introduction que j’ai insérée nous rappelle la nécessité de persister pendant plusieurs semaines (5 semaines si je me souviens bien selon une étude d’une Université américaine) avant qu’un changement devienne une habitude. Donc, commencez dès aujourd’hui à implémenter un changement qui vous tient à cœur, même minime comme tenir une liste des choses à faire que l’on mettra à jour chaque soir, tenez bon pendant 5 semaines et ce sera devenu une habitude qui vous demandera bien moins d’efforts qu’au début.
Le projet est très souvent synonyme de changement: processus de travail, organisation, outils, produits, services… Lorsque vous devez changer les habitudes de vos clients et/ou utilisateurs sur votre projet, il faudra plusieurs jours, semaines, mois peut-être avant que le changement que vous apportez avec votre projet ne devienne pour eux qu’une partie « normale » de leur vie.
En tant que chef de projet, vous constaterez aussi que le changement est difficile pour presque tout un chacun.
Vous pouvez interviewer des parties prenantes, conduire des phases pilotes et obtenir des retours d’information pour un projet qui par exemple change une interface utilisateur opérationnelle et il va probablement y avoir beaucoup de résistance.
Comment pouvez-vous assurer le succès de projet quand il dépend du comportement d’autres personnes ?
Voici quelques astuces pour vous aider à motiver les personnes à changer leur comportement et adopter nouveau Processus.
Chaussez les bottes (ou pantoufles) de vos utilisateurs
Un simple interview ou discussion avec vos utilisateurs ne suffit pas à causer un changement comportemental.
C’était la situation quand un hôpital a embauché des consultants de conduite de projet pour améliorer l’expérience des patients. Dans ce scénario, les consultants n’ont pas interviewé ou examiné les patients. Au lieu de cela, les consultants se sont faits inscrire comme patients et ont dormi dans des lits de patients pendant 24 heures avant de proposer des modifications aux procédures existantes.
Vous devez faire le même dans n’importe quelle sorte de projet. Chaussez les chaussures de votre utilisateur. Ressentez leur douleur. Voyez des choses de leur perspective. Comprenez ce qui est vraiment important pour eux.
Alors, ils pourraient être plus enclins à accepter et adopter le changement.
Attirez l’attention des parties prenantes
Les personnes sont souvent trop occupées pour prêter attention à de nouveaux processus ou des changements de procédures.
Une société d’e-commerce, par exemple, a cherché à mettre à jour son interface opérationnelle. Cela a impliqué de créer de nouveau flux de travail et processus.
Le changement proposé était important et les chefs de projet savaient qu’ils devaient le communiquer aux collaborateurs d’une façon appropriée. Ils avaient besoin d’attirer l’attention des utilisateurs et les atteindre sur un niveau émotionnel pour stimuler un changement comportemental.
Les utilisateurs ont été invités à un feu de joie pour brûler tous les vieux manuels de processus. Cela a capté avec succès leur attention d’une façon visuelle et émotionnelle et a motivé leur changement.
Concentrez-vous sur les Quatre Es
En planifiant un changement de processus ou procédure, assurez-vous que le changement est équitable et bon. Pour aider des utilisateurs à adopter ce changement, concentrez-vous sur les quatre Es:
Engagez des parties prenantes dans le développement du processus;
Expliquez le contexte et l’arrière-plan(le contexte);
Clarifiez les Exigences de conformité au changement de l’utilisateur et les conséquences du refus d’obéissance; et
Faites preuve d’Empathie avec l’utilisateur et les changements qu’ils devront supporter.
Apprenez-en davantage sur la justification du changement dans Project Resistance? Provide Justice, un article publié dans Community Post l’été dernier.
Mesurez ce qui importe
Les mesures pilotent le comportement. Quand vous avez choisi des mesures appropriées et démontré leurs effets, vous pouvez obtenir un impact soutenu sur le changement comportemental.
Par exemple, une organisation a constaté que ses collaborateurs passaient trop de temps dans trop de réunions inefficaces. Les collaborateurs avaient aussi l’habitude de ramener du travail à la maison le soir parce qu’ils n’avaient pas assez de temps pendant la journée pour le compléter.
Les chefs de projet étaient chargés d’un projet afin de changer ce comportement.
D’abord, ils ont mesuré le temps et le coût de chaque collaborateur qui participaient à des réunions régulières. Puis, les chefs de projet ont visuellement affiché ces données et ont montré comment elles avaient un impact sur la productivité.
Quand les résultats du projet ont été présentés, les chefs de projet se sont sentis confiants que les personnes changeraient leur comportement pour conduire des réunions en moins grand nombre, plus courtes et plus efficaces en se basant sur ces données et ces mesures.
1. Préparer un plan. Oubliez les échecs passés, donnez-vous une date et partez de zéro avec un plan robuste.
2. Choisissez un déclencheur. Un déclencheur est un évènement qui lance cette nouvelle habitude et qui si possible vous la rappellera chaque jour.
3. Recevez des feedbacks positifs. Il est facile d’abandonner sans support. Vous devez vous félicitez de vos efforts et vous encouragez vous-même quand c’est difficile en vous rappelant les bénéfices que vous allez tirer de cette nouvelle habitude.
4. Parlez de votre nouvelle habitude sur un groupe social. Annoncez-la sur Twitter, Facebook, ou votre blog. Demandez à vos amis et famille de vous supporter. Demandez leur de vous rappeler votre décision et votre responsabilité.
5. Donnez-vous des récompenses. Elles renforceront votre détermination.
Changer d’habitude est une compétence. Nombreux sont ceux qui échouent par manque de planning ou en essayant d’en faire trop en une seule fois. En réussissant à en changer la première, les prochaines seront de plus en plus faciles à réaliser.
partagez ce billet avec vos amis, collègues et relations professionnelles
Tous les correctifs jusqu’au Cumulative Update (CU) du mois d’avril
Des corrections sur des problèmes référencés
De nouvelles fonctionnalités ou améliorations
Le Cumulative Update (CU) de juin 2011 contient tous les correctifs jusqu’au mois de juin.
Comment l’installer ?
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:
Sharepoint Foundation SP1 puis CU
Sharepoint Server 2010 SP1 puis CU
Project Server 2010 SP1 puis CU
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.
Article écrit par Jean-Baptiste Jourdant, consultant-formateur et Responsable du département Management de projet pour CSP Formation et partenaire de DantotsuPM. Retrouvez cet article sur le blog Management de Projet de CSP Formation à l’adresse suivante : http://www.cultivezvostalents.fr/management-projet/
« – Tiens voilà le planning détaillé.
– T’as utilisé quoi comme logique de découpage de l’OT?
– ???
– Ben oui, pour créer les lots, t’as fait quels choix?
– Tu ne veux pas regarder mon planning plutôt que de me poser des questions métaphysiques? »
Livre de référence sur Amazon
Le constat
Approche classique du chef de projet autodidacte : « quand on doit planifier, on planifie. »
Et quand on doit planifier, on le fait de façon détaillée, tant qu’à faire!
Le problème
Si mon chef me demande « la logique de mon découpage », c’est que dans la planification, cette opération doit servir a quelque chose…
Attaquer directement par la planification détaillée, c’est se couper d’une réflexion structurelle sur la dynamique interne de son projet.
Le découpage va impliquer tout d’abord un regroupement de tâches a l’intérieur de lots. Ensuite cela va nécessiter pour chacun de ces lots un responsable auquel la réalisation sera déléguée. Objectif spécifique, moyens adaptés, contraintes QCD (qualité, couts, délai), et aussi les modalités de réplétive seront définis. Enfin, le choix de structuration de ces taches va imprimer un mode particulier de déroulement, de suivi, et de gestion des problèmes.
Un exemple
Si mon projet est le déploiement d’une solution sur l’Europe. Je peux découper géographiquement (lots FR, SP, IT, GB…), ça tombe sous le sens. Mais choisir un découpage par métier (lots marketing, gestion du changement, production, formation, etc…) est aussi possible.
Pourquoi pas aussi un découpage par cycle : lots définition de la stratégie, configuration, communication, implémentation, test, formation, …
Et alors?
Quelle que soit l’option choisie, elle n’est ni bonne ni mauvaise en soi. Elle doit toutefois respecter quelques précautions:
• ÊTRE CHOISIE. Rien de pire qu’un découpage par défaut, habitude, issue par hasard d’un autre projet
• ÊTRE ALIGNÉE avec les enjeux du projet. Quand une entreprise « choisit » d’organiser le projet de construction de son avion en affectant le cockpit à un pays européen, le fuselage à un deuxième et les ailes à un troisième, c’est l’enjeu politique qui prend la main : construire l’Europe.
• ÊTRE « COMPENSÉE ». Là, il s’agit de prendre en compte la spécificité de son choix et des risques inhérents à cette solution particulière. Pour cela, je vais introduire dans mon management de projet les composantes structurellement manquantes. Si j’ai choisi un découpage géographique, des risques émergent quant à la cohérence métier, technique ou fonctionnelle trans-lots. Je dois donc mettre en place des processus, outils, réunions, de telle sorte que la cohérence métier ou technique soit garantie.
Bien démarrer
A partir d’une lettre de mission, le chef de projet organise une réunion d’acteurs ou d experts
1. BRAINSTORMING SUR POST-IT : toute tache, activité, lot, thème nécessaire au projet
2. REGROUPEMENT de ces éléments en catégorie. A cette étape, il est indispensable d’envisager au minimum 2 possibilités pour avoir un choix
3. LISTER LES AVANTAGES ET INCONVÉNIENTS de chacune
4. CHOISIR UN DÉCOUPAGE en mettant en œuvre les actions permettant de garantir les avantages de la solution non retenue
5. CRÉER LES LOTS, les sous-lots ou macro-taches, puis nommer les responsables,
Ensuite seulement il sera temps de penser à un planning…
CSP est partenaire de DantotsuPM
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
par Jean-Louis Tomas, collègue de très longue date, président fondateur et consultant principal de S.I. ANTIPOLIS, et qui a été responsable du déploiement et de la maintenance de plusieurs ERP en Europe. Jean-Louis Tomas a construit son expertise dans le domaine des ERP en déployant plusieurs sites internationaux. Il a implémenté les modules Finance, Distribution et Production d’Oracle Applications, ainsi que les modules FICO, SDMM et MMPP de SAP dans 16 pays européens.
Jean-Louis nous propose un outil (payant) de calibrage qui me semble unique en son genre et que l’on peut télécharger sur WWW.SI-ANTIPOLIS.COM !
S.I. Antipolis propose en effet un outil créé par des Experts en Projet de déploiement d’ERP (indépendants des Éditeurs et des Intégrateurs) et basé sur une check-list de 85 activités regroupées suivant les 9 phases majeures et fondamentales de l’implémentation d’un ERP.
En vous laissant guider à travers les activités de cette check-list très complète, vous obtiendrez ainsi en moins d’une heure un diagnostic complet sur « l’état de santé » de votre projet ERP. Une analyse graphique immédiate soulignera vos points forts, faibles et vos oublis. Vous confronterez vous-même les activités de déploiement de votre Projet ERP aux meilleures pratiques du marché. Voilà de quoi mettre toutes les chances de succès de votre coté et accélérer le retour sur investissement de votre projet !
Aligner votre Projet ERP avec la stratégie et les objectifs de votre Entreprise
Calibrer interactivement et visuellement vos activités par rapport aux meilleures pratiques du marché
Souligner les points oubliés et ceux à surveiller pour prendre, en temps voulu, les actions correctives nécessaires
Partager cet outil avec vos Équipes Projet et Parties Prenantes afin d’obtenir une analyse commune et objective des changements à apporter
En format Microsoft Excel™, l’outil comprend:
Un tableur interactif basé sur les 3 parties du déploiement d’un ERP : avant, pendant et après
Un graphe résultat pour chacune des 3 parties et global
Les 3 parties sont divisées en 9 phases, elles-mêmes divisées en 85 activités questions-réponses. Vous évaluez votre propre niveau de satisfaction des activités de déploiement de votre Projet ERP sur une échelle de 1 à 10. Les graphes ainsi obtenus serviront de document de travail avec vos Équipes Projet afin d’arbitrer les bons choix.
Vous comparez ainsi, instantanément, l’organisation de votre Projet, vos réalisations et vos plans avec les fondamentaux, les leçons apprises et les meilleures pratiques du marché en termes de déploiement d’ERP.
Une fois téléchargé, l’outil peut être utilisé de manière illimitée dans votre Entreprise. Si vous le désirez, vous pouvez laisser vos coordonnées sans aucun engagement de votre part, afin d’échanger avec un Consultant Expert en Projet ERP de SI Antipolis sur les actions correctives que vous souhaiteriez mettre en place.
partagez ce billet avec vos amis, collègues et relations professionnelles
Article de Neil Stolovitsky, Senior Solutions Specialist, Genius Inside
Les projets les plus remarquables ont souvent une histoire intéressante et ont atteint une certaine reconnaissance pour contribution à la société. Cela s’applique pour l’Empire State Building, connu comme l’un des monuments qui symbolisent le mieux l’espoir durant des périodes noires de l’histoire américaine. Le projet de l’Empire State Building est l’un de ces projets qui montrent que la motivation joue un grand rôle dans le succès d’un projet. Comme tout grand projet, la vision de l’Empire State Building a évolué au cours des années. A l’origine, il devait être un symbole mondial de puissance économique, alors qu’aujourd’hui, il est un symbole mondial de viabilité.
Vision
La vision d’origine de l’Empire State Building a été motivée par une compétition entre deux leaders dans les affaires Walter Chrysler (Chrysler Corporation) et John Jakob Raskob (fondateur de General Motors) pour voir lequel pouvait construire le plus grand building. Ce projet devait donc symboliser la puissance économique et technologique des États-Unis et lui permit de gagner le titre de «plus grand bâtiment du monde» qu’il garda pendant plus de 40 ans.
Durant la crise économique, le projet a atteint sa première vision en créant des milliers d’emplois et en développant à la fois un côté fonctionnel et monumental qui a permis de redonner le moral et de projeter l’image de puissance économique des États-Unis.
Exécution
Il fut conçu par William Lamb, un architecte de la firme Shreve, Lamb & Harmon, en moins de quelques semaines (basé sur un design précédent). Depuis le début, le projet de l’Empire State Building Project avait comme principal objectif d’être terminé le premier. Construit durant la crise économique, l’Empire State Building a été réalisé en moins de 18 mois nécessitant plus de 3,400 travailleurs pour un coût de $40,948,900. Ses portes se sont ouvertes le 1er mai 1931, en qualité de premier immeuble à avoir plus de 100 étages, 6500 fenêtres, 73 ascenseurs, et 1860 marches d’escalier pour aller du rez-de-chaussée au 102ème étage.
Du point de vue de l’exécution, le projet fut un succès car il atteint son objectif avec le titre de plus grand building. Cependant, à cause de la crise économique et de sa localisation, l’édifice fut un fiasco financier pendant 20 ans avec une occupation moyenne de seulement 50%. Pendant plusieurs années, les gens l’ont appelé l’ « Empty State Building » (le bâtiment vide). Il s’agit là d’une bonne leçon pour les professionnels en management de projet.
Résultats
Bien qu’au départ, l’Empire State Building ait souffert financièrement, il a reçu, pendant une période, le titre de l’une des 7 merveilles du monde et est devenu ainsi une icône New-Yorkaise qui attirait les touristes et même acquis une certaine célébrité avec le film King Kong. Tirant profits de son statut d’icône, différents projecteurs furent installés en 1964 qui illuminaient sa façade de différentes couleurs, retraçant d’importants événements de l’histoire américaine, telle que le jour de la St. Patrick (lumières vertes) et le décès de Frank Sinatra (lumières bleues).
En juillet 2010, une fois de plus, l’Empire State Building s’est redéfini comme un symbole, en s’engageant dans un projet d’amélioration de consommation d’énergie à $20 million, visant à montrer les bienfaits de l’écologie. Le succès de l’Empire State Building est dû à sa capacité à renouveler continuellement son image à travers le temps, tout en restant fidèle à son intention première d’inspirer des idéaux de société meilleure. Son succès continuel dépasse le projet lui-même.
Anecdotes – Savez-vous que si les constructeurs de l’Empire State Building avaient utilisés une solution de management de projet, ils auraient pu économiser $511,861.25?
** Ce calcul est basé sur une valeur estimée de 50% du budget alloué à la main d’œuvre et 10% de ces coûts attribués au manque de productivité. Les économies sont calculées sur la norme agréée qui indique qu’un logiciel de gestion de projet permet de réduire les pertes de productivité de 25%.
partagez ce billet avec vos amis, collègues et relations professionnelles
Après les « mainframes », le client/serveur, l’Internet, voici l’avènement du « Cloud Computing » qui combine de nombreuses facettes de leurs avantages respectifs. Gagner en flexibilité, rapidité, sécurité, tout en réduisant les coûts informatiques, telles sont les promesses alléchantes de cette nouvelle déferlante.
Petit rappel en 60 secondes de ce qu’est le Cloud Computing.
Si vous voulez savoir si l’informatique peut détruire de la valeur, si en vous attaquant aux coûts informatiques, vous risquez d’affecter les performances de l’entreprise, s’il est normal de payer la maintenance pour corriger les bugs (donc qu’un produit neuf contienne des erreurs) ou encore si en mettant l’informatique en Inde, l’entreprise sera plus performante économiquement, lisez sans tarder son bouquin !
Depuis que l’informatique est dans tous les maillons de la chaîne de valeur de l’entreprise, elle apporte des opportunités insolites, mais aussi de nouveaux risques qui vont mettre en péril les organisations qui n’y sont pas préparées. Le temps est venu pour les cadres et dirigeants non informaticiens d’en comprendre les enjeux. Cherry Picking 1.0 veut apporter des outils de gestion adaptés pour cela. L’approche économique de l’informatique qu’Yves y développe est le fruit de ses quinze années de pratique professionnelle et de recherches personnelles.
Bonne lecture, piochez dans cet ouvrage quelques chapitres/cerises à déguster en fonction de vos préoccupations du moment.
partagez ce billet avec vos amis, collègues et relations professionnelles
Article écrit par Pascal GILQUIN, Responsable Département FINANCE chez CSP Formation et partenaire de DantotsuPM. Retrouvez cet article sur le blog Management de Projet de CSP Formation à l’adresse suivante : http://management-projet.cultivezvostalents.fr
DE L’OBLIGATION AUJOURD’HUI DE MAÎTRISER DU LANCEMENT A LA CLÔTURE DU PROJET
« Les projets ayant un TRI (Taux de Retour sur Investissement ou ROI) de moins de 14 % ne passent plus cette année, l’actionnaire devient de plus en plus exigeant … »
« Dans ces années difficiles, on me demande d’être plus vigilant et surtout plus réactif d’un point de vue de coûts de projet »
L’avis de l’expert
Dire que les coûts prennent de plus en plus d’importance est un euphémisme ! Aujourd’hui, presque obligé d’avoir de solides connaissances financières dans la conduite de projet !
AVANT LE PROJET : je dois prévoir et estimer au plus juste : il s’agit de garantir à l’actionnaire une rentabilité de capitaux engagés ; sinon, impossible d’obtenir du financement pour mes projets futurs …
PENDANT LE PROJET : Je dois impérativement contrôler si je m’éloigne de mes prévisions et surtout effectuer des actions correctrices rapides afin d’éviter les dérives …
On a même inventé un nouveau mot : LA « COÛTENANCE » ou la science de la maîtrise des coûts !
Le champ d’application
Au quotidien, le chef de projet doit posséder une double casquette de management de coûts :
– BIEN PRÉVOIR, ESTIMER SES COÛTS au plus probable
– MAÎTRISER SES COÛTS PENDANT SON PROJET et proposer des actions correctrices
Cela suppose donc 2 niveaux de connaissances orientés coûts demandant des compétences élargies :
Niveau ESTIMATION DE COÛTS :
Connaître les méthodes globales, paramétriques, modulaires …
Savoir intégrer le coût des risques d’un projet (% d’occurrence, loi statistiques … )
Savoir sortir un taux de rentabilité de son projet
D’un point de vue cash, savoir calculer au bout de combien de temps je récupère ma mise de fonds initiale
Niveau MAÎTRISE DES COÛTS :
Épouser un vrai rôle de coûteneur ! : utiliser la méthode du Reste à faire, contrôler ses dérives, travailler sur avancement physique, jalons, écarts …
Enfin bref maîtriser son coût de projet du début à la fin, il s’agit de tenir à bout de bras son projet sous l’angle COÛTS !
Exemple de mise en pratique Et retour expérience clients
Chez ERAS, (bureau d’études en ingénierie industrielle) chaque chef de projet a un intéressement pour les écarts entre prévu et réalisé inférieur à 5%.
Chaque estimation de ligne budgétaire repose sur un retour d’expérience de projets similaires, une analyse après projet entre budget initial et budget révisé étant faite minutieusement.
Ensuite, chaque ligne budgétaire conséquente est révisée en cas d’écart définitif et le coût prévisionnel automatiquement recalculé.
En tout cas, le chef de projet se doit d’être techniquement bon, bien sûr, mais aussi excellent estimateur avec une bonne perception de la dépense la plus probable. Enfin il doit être un parfait coûteneur avec le calcul régulier de la dérive future, l’outil informatique maison permettant de juxtaposer des données estimatives initiales avec des « re-prévisions » au cours du projet.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Microsoft propose de nombreux « livres blancs » (white papers) relatifs à Microsoft Project Server 2010. Il s’agit de documents de référence, disponibles librement en téléchargement (en anglais essentiellement), traitant d’un sujet spécifique à la solution de gestion de projet de Microsoft.
Globalement, Microsoft a fait un effort louable et conséquent de documentation de Microsoft Project 2010 (alors qu’il était reproché un manque d’informations à la sortie de la version 2007). Il y a également énormément d’informations via les sites officiels TechNet (en français et en version anglaise) et MSDN (plutôt orienté développement).
Les livres blancs sont écrits par des Microsoftees, des partenaires, des MVPs… et font office d’ouvrages de référence.
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.
Pour d’autres articles sur les WBS consultez:
la structure de découpage du projet (Work Breakdown Structure: WBS) Si Philip Diab (former PMI Chair Person) devait identifier un seul outil, méthode ou processus qu’il faut maîtriser parfaitement pour les chefs de projet, ce serait la structure de découpage du projet (WBS). Voici ce qu’il nous en dit.
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:
1) Culture adéquate
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!
2) Adhésion
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.
3) Management du changement
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.
4) Formation
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.
5) Collaboration
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).
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Dans l’écriture pour le domaine professionnel, vous obtenez des bons points pour la clarté, pas pour le style. Au lieu d’essayer d’exprimer de manière poétique les plans de votre division pour les 60 prochains jours, contentez-vous de faire passer votre message. Voici trois façons d’y parvenir:
Une idée par paragraphe. Les romans contiennent plusieurs idées complexes et émotionnelles dans un seul paragraphe. Dans l’écriture pour le domaine professionnel, limitez vos pensées à une par paragraphe. Quand vous avez une autre suggestion, pensé ou idée, débutez un nouveau paragraphe.
Mettez l’essentiel de votre point dans la première phrase. N’enlisez pas vos lecteurs dans des informations de base et de contexte pour construire le point. Personne n’a de temps pour cela. Donnez votre point principal d’abord. Puis aller dans les détails qui supportent ce point.
Rendez-le « survolable ». Peu de personnes lisent chaque mot d’un courrier électronique. Utilisez des en-têtes et des listes à puces pour que votre lectorat puisse rapidement parcourir votre message et comprendre votre point.
partagez ce billet avec vos amis, collègues et relations professionnelles
Article écrit par Jean-Baptiste Jourdant, consultant-formateur et Responsable du département Management de projet pour CSP Formation et partenaire de DantotsuPM. Retrouvez cet article sur le blog Management de Projet de CSP Formation à l’adresse suivante : http://management-projet.cultivezvostalents.fr
Le chef de projet informatique MOE client : « Avec cette nouvelle méthode d’évaluation des charges avec les points de fonction (PF), on croit que tout est résolu, mais le prestataire fait ce qu’il veut avec tous ces ajustements, et on n’est pas plus avancé. »
Le chef de projet SSII : « Depuis qu’ils nous demandent des cotations en PF, on n’a plus de marge de manœuvre. En plus, on ne maîtrise pas les coefficients de productivité, alors on s’engage les yeux fermés, et puis on est coincé. »
La théorie synthétisée
Les PF sont une méthode d’évaluation des fonctionnalités logicielles telles que perçues par les utilisateurs (finaux, administrateurs métiers) de l’application. A travers différents composants (groupes de données, transactions) l’application est cartographiée puis valorisée en nombre de PF.
Puis, à l’aide d’un coefficient de productivité (nombre de PF produits par homme.jour), on calcule la charge estimée du projet.
Intérêt
Le PF n’est certainement pas une panacée universelle. Toutefois, il permet d’établir un référentiel compréhensible par tous les interlocuteurs de la chaîne de production. La MOA voit ses fonctionnalités (disséquées, certes), la MOE client va disposer d’une base de comparaison entre ses différents projets (à manier avec précautions), la MOE SSII va disposer d’une image fonctionnelle « anticipée » de ses composants techniques, et faire valoir directement les carences éventuelles.
Les éléments variables
Les différents éléments suivants sont évalués pour prendre en compte les spécificités.
PRODUIT : nouveauté logicielle, complexité du langage, progiciel, niveau d’ergonomie ou de sécurité demandée, réutilisation du code, …
PROJET : Organisation de l’équipe (plateau de développement unique ou éclatement de la réalisation (off-shore), niveau de compétences des acteurs, urgence planning, …
MODÈLE DE PRODUCTION : Répartition des activités entre le client et le prestataire (RTU-Réalisation & Tests unitaires, conceptions, tests d’intégration, pilotage, prise de risques, …)
Processus de calcul des charges
Entre la fonctionnalité et les charges, le chef de projet passe par plusieurs étapes :
1° Cartographie : Nombre de PF dits bruts
2° Ajustements produits : Nombre de points de fonction ajustés
3° Utilisation du ratio de productivité standard : Charge nominale
4° Intégration des spécificités projet (périmètre RTU) : Charge brute
5° Prise en compte du modèle de production : Charge nette
Exemple
1° Cartographie fonctionnelle =>100 PF Bruts
2° Ajustement produit (sécurité, techno), +20% =>120 PF Ajustés
Finalement, dans la méthode, pour passer à l’étape suivante, on utilise un ratio qui mesure la contribution de chaque catégorie.
Et pour une productivité nominale de 2 PF/HJ, on a en réalité entre les PF bruts et la charge nette, une productivité globale de 0,88PF/HJ : 100 PF / 112,5 HJ
Recommandations
CONTRAT : C’est votre contrat qui fait foi. Précisez le ratio de productivité sur lequel vous vous appuyez. Et attention aux engagements préliminaires quand vous ne disposez pas de références.
MARGE DE MANŒUVRE : Soyez clair entre clients et fournisseurs sur les éléments variables et cadrer leur influence.
CAPITALISATION : C’est le secret de la fiabilisation de vos ratios de productivité !
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Voici 10 bonnes raisons d’appliquer les principes et pratiques de développement agiles …
1. Revenus
La 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é.
2. Vitesse de commercialisation
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 ».
3. Qualité
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é.
4. Visibilité
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.
5. Management des risques
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.
6. Flexibilité / Agilité
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.
7. Contrôle des dépenses
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.
9. Le bon produit
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.
10. Plus agréable !
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.
Les implications d’embrasser des principes de développement Agile
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.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Les mnémoniques SMART et SMARTER sont fort utiles lors de la définition des objectifs du projet.
Ils fournissent une assurance que tous comprennent bien les objectifs de votre projet, qu’ils sont traçables, mesurables, significatifs, que nous avons suffisamment de ressources pour les atteindre, et que l’objectif temps est clair.
Essayez de remplir ces 7 dimensions pour les objectifs de votre projet.
L’occasion était top belle pour la manquer. Félicitations à Yves (3ème en partant de la gauche sur le rang du haut) qui a brillamment suivi les formations de Leadership proposées par PMI aux volontaires de ses chapitres dans le monde entier. Voici une bonne raison de plus de vous porter volontaire pour participer au rayonnement du management de projet dans votre région à travers les branches locales de PMI.
partagez ce billet avec vos amis, collègues et relations professionnelles
Dans la gestion de projet Agile, nous devons prioriser une liste de demandes pour la planification de version, d’itération et l’insertion de nouveaux besoins ou exigences. Mais il y a plusieurs techniques pour le faire.
Une des méthodes les plus populaires pour déterminer la priorité des demandes est l’approche dite « MoSCoW ». Cela signifie ‘ Must (Doit), Should (Devrait), Could (Pourrait), Won’t (ne fera pas). ‘ Le seul problème avec cette méthode est que d’habitude tout est un Must, ce qui ne permet pas une planification appropriée parce que les besoins ne sont pas nécessairement placés dans leur ordre de priorité.
Une autre méthode estle modèle de Kano, développé par le Professeur Noriaki Kano, qui s’efforce de satisfaire les exigences et de faire plaisir aux clients. Ce modèle dispose de quatre composants :
• Must haves (doit avoir) sont des éléments sans lesquels on ne peut livrer le produit.
• Dissatisfiers (générateurs d’insatisfaction) sont des choses que le produit ne doit pas inclure.
• Satisfiers (générateurs de satisfaction) incluent besoins pour lesquels plus vous en avez mieux le produit sera perçu. Comme un catalogue commercial dans lequel chaque fonctionnalité ajoute progressivement de la valeur.
• Delighters (générateurs de plaisir) amènent le produit plus loin que simplement répondre aux exigences vers l’augmentation de la satisfaction client et la recommandation par le client.
Plusieurs modèles de priorisation réunissent deux variables dans un tableau pondéré : fonctionnalités et clients. Chaque fonctionnalité est pondérée par sa valeur pour chaque client. La somme des poids multipliés par le score permet de voir quelles fonctionnalités sont en général les plus utiles pour un jeu de clients exigeants.
Quel que soit la technique utilisée, votre liste d’exigences de projet doit être triée de la plus grande à la plus faible valeur.
Quelles techniques utilisez-vous pour prioriser les besoins ?
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Source: Gartner (June 2011)
asy Steps
DantotsuPM.com 