Bien que toutes les sessions se déroulent sur une journée, le 5 novembre prochain, elle seront enregistrées et resteront en ligne pendant 90 jours pour nous donner le temps de visionner toutes celles qui nous intéressent (et ce, jusqu’au 3 février 2016). Sur 3 mois, nous devrions avoir le temps de ne rien rater de cet événement annuel devenu un incontournable pour tous ceux qui souhaitent suivre l’évolution du management de projet et s’améliorer en permanence: Donc, pour tous les lecteurs du blog DantotsuPM 🙂
En plus d’intervenants de renom qui partageront leurs expériences et leurs idées, les participants auront droit à 3 formations (en supplément aux 20 PDUs de la journée).
Donc, si vous êtes en manque d’informations sur le management de projet et peut-être aussi de PDUs, venez y raflez votre quota annuel, voire prendre un peu d’avance.
La WBS ou Structure de Découpage est une décomposition hiérarchique du contenu total du projet. Elle définit et organise les livrables du projet et supporte le chef de projet dans la planification de ses activités.
Cet outil, qui prend la forme d’un tableau (qui croise la WBS et les ressources de l’organisation) permet au chef de projet de lister les participants au projet ainsi que leur(s) responsabilité(s).
C’est la Charte de Projet, le plus souvent rédigée par les sponsors et par le chef de projet lui-même, qui initie le projet et valide l’alignement du projet avec la stratégie de l’organisation.
Plusieurs articles sur bien préparer votre prochain entretien d’embauche :
De temps en temps les choses peuvent devenir très compliquées pour les chefs de projet. C’est bien le cas, n’est-ce pas ? Nous avons à superviser de multiples équipes et membres d’équipes et devons interagir avec de nombreuses organisations et parties prenantes. Chacun veut obtenir quelque chose et de façon différente. Les gens parlent des langages différents, communiquent différemment et hé, c’est compliqué.
Pour faire remonter les informations courantes et problèmes liés à leur salle à leur responsable et au siège, les managers utilisaient l’emailing [la messagerie électronique] : incidents, informations et tâches étaient ensuite répertoriés dans Excel. Wellness Training a fait le constat d’une perte de temps et d’informations lié à un modèle classique d’échange d’information et a opté pour un outil de gestion de projet collaboratif.
Après avoir observé un tableau de suivi des tâches de Scrum, j’ai vraiment aimé l’idée d’un tableau blanc physique pour visualiser le flux d’un projet. Le système entier de Scrum ne marcherait pas vraiment pour une équipe d’ingénieurs systèmes puisqu’il semble se concentrer sur un unique projet, ce qui n’est pas le cas dans l’ingénierie de système. Alors comment se servir tout de même des concepts Kanban ?
partagez ce billet avec vos amis, collègues et relations professionnelles
What would happen if you funded every single new product idea from any employee, no questions asked ?
Learn why Adobe is giving away $1000 for free to any employee who wants to innovate and how it might change your organization.
As a serial entrepreneur, Mark Randall’s career conceiving, designing and marketing innovative technology spans nearly twenty years and three successful high-tech start-ups. He sold his most recent startup, Serious Magic, to Adobe Systems where he is now Chief Strategist, VP Creativity.
His talk raises the following question: What would happen if you funded every single new product idea from any employee, no questions asked?
As an experiment, Adobe did exactly that. Mark Randall shares the surprising discoveries from creating Kickbox, the radical new innovation process helping drive Adobe’s remarkable success. Each employee receives a mysterious red box packed with imagination, money and a strange game with six levels. Mark explains how aligning passion with purpose changes everything and how trust can transform good people into great innovators.
Learn why Adobe is giving away the Kickbox process for free and how it might change your organization.
partagez ce billet avec vos amis, collègues et relations professionnelles
Relation « gagnant-gagnant » avec MSP, le guide de Management de Programme du Cabinet office.
Jeff Ball
Dans les grandes lignes, MSP cible les programmes transformationnels. Ceux-ci livrent un changement. Ils changent la façon de travailler d’une organisation, ou livre un changement dans un environnement de service social ou public.
Certaines entreprises ont souvent quatre profils de collaborateurs à former :
Chef de programme
(staff du) Bureau de programme
Chef de programme du programme client
Responsable de la conduite du changement
Profil 1 : Chef de programme
Le premier profil est le chef de programme, qui traite des programmes de transformation interne. Cela est le programme « typique » de MSP, un programme de transformation interne qui conduit au changement organisationnel.
Profil 2 : (staff du) Bureau de programme
Le deuxième profil est un rôle nouveau, à savoir le staff du Bureau de Programme. L’entreprise a un bureau de programme permanent, pour soutenir le travail de transformation interne.Le chef du Bureau de Programme et un équipier aideront au déploiement et à la maintenance de MSP pour les programmes de transformation interne, en fournissant notamment des modèles (templates) et conseils. Et aussi plus activement, ils devraient jouer le rôle de Bureau de Programme dans les programmes, faciliter la surveillance et le contrôle, et servir de central (hub) d’informations pour les programmes.
Partenaire de DantotsuPM
Le troisième et le quatrième profil emmènent MSP dans la dimension « client-fournisseur ». Quand l’entreprise fournit des solutions business complexes à ses clients, il y a des bénéfices à utiliser MSP pour élargir le champs de « simple » livrable technique à des résultats plus larges, créateurs de valeur ajoutée.
Profil 3 : Chef de programme du programme client
Le troisième profil est donc le chef de programme du programme client. Il ou elle profite de la formation MSP en gérant les programmes différemment. Cela viendra de la compréhension de la différence entre les productions techniques (par exemple le nouveau serveur proxy) et les bénéfices client (par exemple améliorer les télécommunications, les vidéoconférences, réduire les coûts de télécommunications). Avec MSP, vous reconnaissez la proposition générale de valeur du programme, pas seulement ses livrables techniques.
Profil 4 : Responsable de la conduite du changement
Le quatrième profil est peut-être le plus intéressant, puisque c’est le rôle de soutien au client. Aujourd’hui ce rôle prend le relai quand les projets finissent, afin de s’assurer que le client peut utiliser ce que les projets ont livrés. En utilisant une approche MSP, ce rôle devient le RCC (Responsable de la Conduite du Changement). Il travaille activement avec les équipes de projet pour garantir qu’elles voient plus loin que les livrables techniques. En tant que RCC, il ou elle préparera au changement business, le fera avancer et travaillera pro activement avec le client pour garantir la réalisation des bénéfices.
Ces deux derniers rôles se focalisent sur la chaîne de valeur globale. Elle inclut les bénéfices client, pas juste la rentabilité du fournisseur. Ceci est un changement dans la façon de penser. Et ce n’est pas au détriment du cas d’affaire du fournisseur – en utilisant une approche MSP, le chef de Programme obtiendraune visibilité sur le travail du fournisseur dans le cadre plus large du programme et pourra aussi voir laproposition de valeur pour le client.
Partenaire de DantotsuPM, LE blog du management de projet
C’est une approche « gagnant-gagnant », qui remplace l’actuelle solution « perdant-perdant » où les projets du fournisseur semblent profitables, mais les profits disparaissent dans de coûteuses activités de support post-projet afin de résoudre des problèmes clients (et un client mécontent est souvent un client perdu).
Pour résumer : en se positionnant sur la proposition de valeur globale du programme, on engendre des profits pour le fournisseur et la satisfaction du client.
Les quatre premières étapes du modèle de développement d’équipe furent développées par Bruce Tuckman en 1965. En 1977, Tuckman s’associa avec Mary Ann Jensen et ajouta la 5ème étape : Dissolution.
Un billet de Sabrina Loufrani-Fedida, avant-dernier d’une série de 5. Pour notre synthèse, nous nous fondons sur le PMBok(PMI, 2009), parce qu’il est largement utilisé comme base d’évaluation des compétences par de nombreuses compagnies en Europe et ailleurs. Nous avons choisi de classer ces compétences en trois catégories…
Nous voudrions terminer notre propos sur la « face cachée » ou le « côté sombre » du management de projet (Asquin et al., 2007). Le management de projet incarne, dans une certaine littérature managériale, le mythe de l’action heureuse, voire exaltante dans les projets entrepreneuriaux.
Voici le premier d’une série de 3 articles qui nous mèneront de la gestion de projet « traditionnelle » à l’Agilité ! La gestion de projet «traditionnelle» n’est pas nécessairement celle documentée dans le PMBoK, le Project Management Body of Knowledge, du PMI (Project Management Institute). Bien que ce document ne soit pas parfait, il est en évolution constante et inclut maintenant dans sa dernière édition plusieurs des principes de l’agilité.
Second billet. Nous pouvons voir qu’un projet qui livre «dans les temps et dans les coûts», comme unique préoccupation, ne livre pas plus que 30% des bénéfices possibles.
Le Mooc ABC Gestion de projet annonce sa cinquième édition, le 9 mars 2015 avec Rémi Bachelet, enseignant à l’Ecole Centrale de Lille. Ce cursus comporte quatre semaines de tronc commun et une semaine pour valider deux des sept modules optionnels.
Bonjour, comme cela me l’a été demandé plusieurs fois, j’ai actualisé ce billet sur un sujet toujours très prisé (et nous le comprenons) des personnes qui se lancent dans le projet de passer la certification PMP®: quelles ressources et comment s’y prendre ?
Petit truc à savoir… pour connaitre tous les certifiés de votre sélection mettez le signe « % » dans le champ obligatoire « Last Name » puis choisissez (si vous le souhaitez) le pays et la certification qui vous intéressent.
Partenaire de DantotsuPM
Et côté Prince2, MOP, MSP, P3O, MoV, M-o-R, ou encore ITIL: qui détient ces certifications ?
Récemment, une revue de rôle avec plus d’un millier d’agilistes œuvrant dans 60 pays a permis de mettre à jour la description des pratiquant des méthodes Agiles. L’examen pour la certification PMI-ACP® est en cours d’adaptation très Agile.
En quoi le PMI-ACP® change-t-il?
Un nouveau domaine apparait: Les principes et l’état d’esprit Agile (Agile Principles and Mindset). Ses concepts existaient bien sûr déjà dans les 6 domaines de bonnes pratiques (qui deviennent 7) mais était disséminé sur ceux-ci.
62 tâches ont été validées dans de contexte de ces 7 domaines:
Check this past article and Video
Agile Principles and MindsetDomain (NOUVEAU)
Value-driven DeliveryDomain
Stakeholder EngagementDomain
Team PerformanceDomain
Adaptive PlanningDomain
Problem Detection and ResolutionDomain
Continuous Improvement (Product, Process, People)
Partenaire de DantotsuPM
Dates
Un pilote est en place du 15 Juillet au 15 Octobre pendant lequel vous pouvez obtenir 20% de réduction sur votre inscriptionTous les détails sur le site du PMI, ici.
partagez ce billet avec vos amis, collègues et relations professionnelles
Le management des changements, des bénéfices et des parties prenantes sont des thèmes phares dans le management de projet d’après ce que je vois et lis sur l’évolution des méthodologies.
Aussi, cette question peut-elle venir à l’esprit de votre interviewer et recruteur.
Vous pourriez en lister quelques-unes comme :
Les clients
Grille Intérêt-Pouvoir
Les utilisateurs finaux (internes et externes)
L’équipe projet, la « core team » dédiée au projet ainsi que l’équipe étendue avec tous les participants
Le sponsor
Le bureau de projets ou PMO
Le Directeur de Programmes si le projet fait partie d’un Programme
Le management opérationnel et les directions fonctionnelles
Les partenaires et fournisseurs
Les autres personnes pouvant être impactées par le projet
…
Veillez à trier ces acteurs par ordre d’importance en fonction du projet en vue et ne pas oublier les plus éloignés.
Quelles autres parties prenantes ajouteriez-vous à cette liste de départ?
Le nombre de Dunbar représente une limite théorique au nombre de personnes dans un groupe qui peuvent entretenir des relations sociales stables. Des relations sociales stables sont nécessaires pour supporter l’application des valeurs, principes et techniques Agile. Le nombre de Dunbar est souvent cité comme étant de 150 personnes. Cependant, la limite pour n’importe quel groupe est non seulement le reflet d’une limite comme le nombre de Dunbar, mais aussi dépendante du contexte. Si nous acceptons qu’il y a une certaine limite théorique que nous ne pouvons pas dépasser comme le nombre de Dunbar, nous devons nous demander comment d’autres projets ou facteurs exogènes contraignent encore davantage le nombre maximum de personnes travaillant sur un problème. Pourquoi se donner tant de mal pour augmenter le nombre de personnes travaillant sur un problème ? Beaucoup d’Agilistes suggéreraient qu’une unique petite équipe est optimale. Cependant, beaucoup de problèmes exigeront une plus grande collation d’équipes pour délivrer la valeur et la fonctionnalité.
Les éléments contextuels supplémentaires qui modifient le nombre maximum théorique de personnes dans un groupe ou une équipe d’équipes incluent au moins quatre facteurs:
1. Cohésion
Ou dans quelle mesure les gens restent ensemble. Il y a beaucoup d’attributs qui peuvent produire la cohésion.
Les exemples incluent : grandes idées, objectifs, nationalités, religions et même identité d’entreprise.
La cohésion favorise une relation commune qui entraine les groupes à investir volontairement davantage d’efforts pour atteindre un but. Par exemple, il est souvent difficile de réaliser un groupe cohésif quand les membres viennent de multiples et externes entités de conseil. Chaque organisation impliquée dans le groupe a un jeu différent de buts organisationnels qui réduisent la cohésion à moins qu’ils ne soient subjugués par l’objectif du projet. La réduction du nombre de personnes en-dessous du nombre de Dunbar rend plus facile l’utilisation de techniques comme la pression entre pairs pour institutionnaliser une vision de projet qui augmente la cohésion.
Est une mesure du nombre de propriétés d’un projet qui sortent de la norme.
La complexité d’un problème réduit le nombre maximum optimal de personnes qui peuvent être impliquées parce que la complexité exige généralement plus de contrôle et de coordination ou des équipes plus petites pour assurer la collaboration.
3. Incertitude
Survient quand les équipes cherchent une réponse à un problème business ou technique.
Quand une équipe doit aborder un problème métier inconnu ou une nouvelle technologie, de la recherche est souvent nécessaire. La recherche est généralement contrainte à de petites équipes avec des compétences spécialisées ce qui réduit la taille de groupe maximale optimale pour ce type d’effort bien en dessous du nombre de Dunbar.
Comme on découvre des concepts et des idées, certains peuvent être déployés plus largement pour être étoffés, prototypés et implémentés en augmentant le groupe travaillant sur le projet en direction du nombre de Dunbar.
4. Dépendances
Quand elles existent entre des composants, cela signifie souvent que le travail doit être concentré (ou du moins s’étendre moins largement).
Les dépendances réduisent le nombre de personnes et d’équipes qui peuvent être efficacement utilisées.
L’idée d’augmenter le nombre de personnes et d’équipes travaillant sur un projet semble souvent être un mécanisme pour délivrer de la valeur plus rapidement. En ajoutant des personnes, il est suggéré de se souvenir que le nombre de personnes travaillant sur un problème est une contrainte qui ne peut pas être traitée en augmentant linéairement le nombre de personnes impliquées sur un problème jusqu’à atteindre une limite comme le nombre de Dunbar.
Le contexte a un impact direct sur la taille que tout groupe peut atteindre avant que l’administration et autres contraintes en réduisent l’efficacité. Il est souvent dit que neuf femmes ne peuvent pas faire un bébé en un mois. En plus du nombre de Dunbar, le contexte joue un rôle important dans la définition de la taille totale de l’équipe.
In the age of technology and high-speed living, it’s often too hard to step back, slow down, and breathe. Prioritizing regular interactions with nature is proven to have immense tangible benefits – and, as Brooks’ experience illustrates, it may be the intangible benefits that are the most valuable of all.
partagez ce billet avec vos amis, collègues et relations professionnelles
Voici une question qui peut vous être posée en entretien pour un poste de Chef de projet ou de PMO.
La « Work Breakdown Structure (WBS) » ou Structure de Découpage de Projet (SDP) en français est développée pendant la phase de planification. Elle décrit tout le travail qui doit être fait pour compléter le projet. C’est une décomposition orientée produit de toutes les tâches qui organise et définit le périmètre total du projet. Elle reflète aussi souvent la façon dont les coûts et le progrès du projet seront regroupés, sommés et rapportés. C’est une structure hiérarchique qui devient plus détaillée comme vous détaillez les tâches, attributions, durées, coûts, produits/livrables, dépendances et contraintes de votre projet.
1 tâche = 1 personne + 1 action + 1 livrable
Diagramme de Gantt des différentes tâches de la WBS et de leur progrès
Ma recommandation personnelle en passant en revue une WBS en sus de sa complétude et de sa structure, est de vérifier qu’une tâche représente clairement une action à réaliser par une personne pour produire un livrable afin que la responsabilité et ce qui est à réaliser soient 100% limpides. Je vérifie aussi que les durées de chaque tâche n’excèdent pas 2 semaines sur un projet de 12 mois pour faciliter un suivi de progrès régulier.
Now Available : The Global State of the PMO: An Analysis for 2015
With a growing level of maturity, the Project/ Programme Management Office (PMO) has become deeply entrenched in many organisations worldwide. In its annual survey, ESI International investigated the evolution of the PMO’s function, its role and value in the organisation, and its involvement in training project management professionals.
Some of the key findings :
PMOs are increasingly providing support at the strategic and portfolio level.
PMOs have a long way to go when it comes to demonstrating value through considered, quantitative measurement and metrics.
Two in five PMOs use the Agile approach in some of their projects/programmes.
74% of respondents believe that their PMO Budget will increase or remain the same.
Only 46% of PMOs surveyed offered a defined PMO career path for staff.
76% of PMOs has been challenged by the senior management (Resource management as greatest perceived challenges).
The PMO’s role is significant in Training with 66% of PMOs involved in training.
30.000 ressources pédagogiques accessibles gratuitement, destinées aux étudiants, aux enseignants, aux chercheurs, aux professionnels et plus généralement au grand public et proposées sous forme de cours, conférences, Q.C.M., listes de références, etc.
Pour le management de projet et la gestion de projet, vous y trouverez des retours d’expérience, des descriptions de projets, des outils et vidéos, des MOOCs, des présentations thématiques…
Rappel des billets spécifiques aux MOOCs en management de projet déjà publiés sur DantotsuPM.
Thank you Elizabeth Harrin for giving so much free materials to all project managers !!!
don’t miss to visit the web site
Project Management in the Real World: free chapter
Check the book
Get a free chapter of my first book, Project Management in the Real World, on creating a realistic project budget. It’s actually the first 25 pages of the book, so you get a great glossary of project management terms as well. Get instant access to the document (.pdf)
Get Started Using Social Media on Your Projects: free e-learning course
Sign up for Elizabeth’s free six week, self-paced e-learning course. You’ll learn everything you need to know to take your first steps with using social media tools on your projects. Read more about it.
Partenaire de DantotsuPM
Inside PRINCE2: free ebook
Get your copy of the Inside PRINCE2 ebook. It’s a great introduction to PRINCE2, but it’s also useful for people who aren’t PRINCE2 Practitioners (or who aren’t aiming to be) because it also covers project tolerances, fixed date projects and other stuff useful for all project managers. Get your free copy (about half-way down the page).
Partenaire de DantotsuPM
Books and software reviews
Elizabeth has been reviewing project management books and project management software for over 5 years now, so there is a library of information available for you before you make an investment in reading material or software tools. Check out the index of book reviews and the index of software reviews.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Nous approchons des vacances d’été et, comme nous le rappelle Elizabeth, même si nos projets ont extrêmement bien fonctionné cette année, nos délais soigneusement planifiés ne sont plus toujours bien alignés sur les dates pendant lesquelles nous allons nous absenter…
Voici un aperçu de quelques-une des astuces d’Elizabeth pour s’assurer que vos projets se poursuivent en souplesse pendant que vous êtes loin. Le billet entier est disponible à l’adresse ci-dessus en langue anglaise.
1. Utilisez votre signature de courrier électronique en anticipation de votre départ !
Signature de courrier électronique, coordonnées, Etc
et y ajouter
« Attention : je serai en congés du vendredi 14 août au vendredi 28 août »
Le texte est normalement en rouge ou caractères gras (ou tous les deux) donc il se détache. Cela permet aux gens de vous contacter avant votre départ s’ils pressentent une urgence.
2. Déléguez vos projets
Vos délégataires n’ont pas besoin de connaître tous les détails du projet.
Ils doivent simplement être mis au courant :
Des livrables principaux pendant votre absence
Des risques majeurs ou problèmes actuels
Des parties prenantes critiques et coordonnées du sponsor de projet
Où trouver plus d’informations sur le projet
Les décisions majeures qui devraient être prises pendant vos vacances, le cas échéant, et quelle serait votre recommandation et/ou critères pour prendre cette décision.
Faites une réunion avec ces personnes et créez avec elles un document avec tous les points clés. N’oubliez pas de mettre en place les délégations dans les systèmes informatiques.
3. Prévenez votre sponsor
Dites aussi à l’avance aux parties prenantes clés que vous allez partir. Dites-leur qui contacter pendant votre absence.
Partenaire de DantotsuPM
4. Soyez précis dans votre message de réponse automatique
Je suis au congé annuel jusqu’au vendredi 24 juillet 2015 inclus. Je n’aurai pas accès à mon courrier électronique pendant cette période. Si votre question est urgente, contactez s’il vous plaît :
Projet Alpha: John Smith (numéro de téléphone et courrier électronique) Factures : équipe de gestion des comptes fournisseurs (appelez ce numéro puis l’option 3) Toute autre requête : Emma Jones (numéro de téléphone et courrier électronique)
Je vous répondrai à mon retour.
Rappelez-vous de mettre aussi à jour votre message vocal.
Partenaire de DantotsuPM
5. Anticipez votre retour
Bloquez du temps dans votre agenda à votre retour reprendre à charge votre projet de la personne qui s’en occupait pour vous.
Ces quelques étapes devraient vous aider à vous sentir plus confiants à l’aider de laisser vos projets quelle que soit la durée de votre absence.
Bonnes vacances !!!!
Avez-vous d’autres astuces à suggérer ?
partagez ce billet avec vos amis, collègues et relations professionnelles
AgileBA professional training and certification – the latest product of our long-standing partnership with DSDM Consortium – is now available.
The Business Analyst is a critical role within an agile project team and with more and more organizations adopting agile approaches, we need to ensure those performing this crucial role have the necessary skills and expertise.
Partenaire de DantotsuPM
The syllabus and exams are based on the AgileBA Handbook (published by DSDM). The Handbook offers the first comprehensive set of guidance, framework and practices for the business analyst working on an agile project.
Book Information
AgileBA is the first comprehensive set of guidance, framework and practices for the business analyst working on an agile project.
It also gives context to the Agile Business Analyst role beyond the individual project, in relation to organizational mission and strategy, providing additional depth and guidance for business analysis in an agile context.
The AgileBA Handbook is intended to give useful, practical and comprehensive advice to the Agile Business Analyst.
The guidance is presented within the framework of DSDM, with many generic and popular agile techniques also included.
Training and certification has been designed to give the Business Analyst the skills needed to successfully gather, analyse, validate and champion the requirements throughout an Agile project.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Question d’entretien de PMO et/ou assurance qualité projet…
Il y a quelques principes auxquels je resterais personnellement fidèle et que j’exposerais dans ma réponse :
Pas de blâme personnel : La revue de projet n’est pas une évaluation du chef de projet, ni des membres de l’équipe de l’équipe projet.
Rentable : les coûts de la revue ne doivent pas excéder les bénéfices attendus de la revue de projet.
Sélectif (quand cela a du sens) : Rendre la revue de projet obligatoire pourrait être contreproductif. Utilisez des critères tels que budget, niveau de risque, degré d’innovation, expériences passées, importance stratégique… pour choisir les projets à auditer.
Normalisé (mais flexible) : des modèles et guides doivent supporter les chefs de projet dans la réalisation d’auto-évaluation objectives.
Participation de l’équipe : l’équipe projet est impliquée dans le processus de revue de projet pour réunir des retours d’information qualitatifs aussi bien que quantitatifs.
Basé sur la métrique disponible : la revue de projet repose sur la métrique standard qui se trouve dans les documents de management de projet et qui est accumulée tout au long du cycle de vie projet. Il ne s’agit pas d’inventer de nouvelles mesures, ni de prendre par surprise le chef de projet. Les données demandées devraient être connues selon les pratiques en place dans l’entreprise.
contactez-nous pour publier une annonce
Orienté vers l’action : la revue de projet propose un plan d’actions à implémenter pour une amélioration notable en fonction des observations et leçons apprises.
Suivi : le PMO suit le plan d’action jusqu’à ce que les améliorations proposées et agréées soient implémentées.
En déterminant de quelle taille un programme Agile pourrait être, un des « faits » souvent cité est que le nombre de personnes impliqué dans un programme Agile est soumis au nombre de Dunbar. Le nombre de Dunbar est la limite du nombre de personnes dans un groupe qui peuvent entretenir des relations sociales stables. Le terme, relation sociale est le reflet d’interactions régulières, la capacité de reconnaître un autre membre dans le cadre du groupe ou d’être engagés sur un but commun. Ces attributs sont importants pour tout projet et sont peut-être plus importants dans les projets Agile parce que ceux-ci comptent sur la cohésion d’équipe pour minimiser les mécanismes de contrôle et la bureaucratie.
Le concept du nombre de Dunbar est basé sur de la recherche à l’origine exécutée par les observations de primates et étendue ensuite aux humains au début des années 1990. En juin 1992, Robin Dunbar publié « La taille du néocortex comme contrainte de la taille de groupe chez les primates » dans le Journal of Human Evolution (Volume 22, Edition 6, juin 1992, pages 469-493). Dans ce papier, Dunbar a mis en évidence une corrélation entre la taille du cerveau d’un primate et la taille moyenne de groupe social.
En résumé, Dunbar a écrit :
La taille de groupe se révèle être une fonction de volume néocortical relatif, mais les variables écologiques ne le sont pas. Ceci est interprété comme l’évidence en faveur de la théorie d’intellect social et à l’encontre des théories écologiques. Il est suggéré que le nombre de neurones du néocortex limite la capacité de traitement de l’information de l’organisme et que ceci limite alors le nombre de relations qu’un individu peut contrôler simultanément. Quand la taille d’un groupe excède cette limite, le groupe devient instable et commence à se fragmenter. Ceci situe alors une limite supérieure pour la taille des groupes que n’importe quelle espèce donnée peut entretenir comme des unités sociales cohésives dans la durée.
Bien que la taille de groupe de 150 soit souvent citée comme le nombre de Dunbar, 150 est une approximation.
Comme indiqué dans le « Les limites d’Amitié » (Limits of Friendship) par Maria Konnikova (7 octobre 2014) le nombre de Dunbar peut aller de 100 à 200 personnes selon des facteurs comme le fait d’être sociable. D’autres limites de taille de groupe ont aussi été publiées par d’autres docteurs comme Peter Killworth et Russell Bernard qui indiquent plus de 200 personnes.
Selon le nombre de Dunbar, le Scaled Agile Framework Enterprise (SAFe) suggère que les plus grandes Releases Agile (ART) pourraient inclure environ 150 personnes. L’ART est supporté par un cadre (le framework SAFe), une hiérarchie ( des ingénieurs de Release et des ScrumMasters) et une bureaucratie (un management de produit et des propriétaires de produits). Quand Agile est pratiqué par une équipe de 5 à 9 personnes cette « surcharge administrative » ne serait pas nécessaire pour assurer la coordination.
La mise à l’échelle d’Agile est un numéro d’équilibriste entre efficacité des techniques Agiles au niveau de l’équipe et les concessions faites pour contrôler quand Agile est utilisé sur de plus grands efforts.
Historiquement, les très grands projets ont tendance à être moins efficaces. Capers Jones dans Applied Software Measurement, Third Edition (P295) indique que la productivité chute pour tous les types de projets lorsqu’ils excèdent 1000 points de fonction. Les points de fonction sont une méthode du standard ISO pour mesurer la taille du logiciel basée sur un ensemble de règles standard. Tout simplement, plus un projet est grand en points de fonction et plus grande sera l’équipe (ou l’équipe d’équipes) qui devra livrer le projet. D’où le besoin de plus de contrôle toutes choses égales par ailleurs. Il met en exergue (p 307) le fait que comme la taille de projet augmente, la probabilité d’annulation croit pareillement.
Le livre référence
La montée en volume d’Agile nécessite beaucoup de techniques utilisées au niveau d’une équipe Agile, comme la petite taille d’équipe, le travail par petits lots de fonctionnalités et Scrum. Ces techniques sont très « Lean », mais limitées par la quantité de valeur qui peut être délivrée dans une période spécifique de temps. Comme les projets Agiles grandissent en taille, des techniques supplémentaires sont nécessaires pour maintenir le contrôle. Le nombre de Dunbar (ou des idées similaires) fournit une limite pour essayer d’éviter de laisser un travail devenir trop important pour être gérable. Le nombre agit comme une limite au nombre de personnes impliquées dans un travail. L’application de contraintes supplémentaires, comme des releases ou des incréments de programme SAFe, ajoutent la dimension de temporalité comme contrainte. La combinaison des contraintes sur le nombre de personnes et combien de temps ces personnes travailleront fournit une contrainte explicite de combien de travail peut être livré.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
J’avais déjà à l’époque beaucoup apprécié sa synthèse des facteurs qui influent sur la performance d’une entreprise selon cinq forces :
le pouvoir de négociation des clients ;
la menace de nouveaux entrants potentiels ;
le pouvoir de négociation des fournisseurs ;
la menace de produits de substitution ;
l’intensité de la concurrence intra sectorielle.
De plus, ces cinq forces peuvent être utilisées au plan personnel.
Elles expriment également toute leur puissance lorsque vous les appliquez à vous même, à votre job, à votre contribution dans l’entreprise, et ce, quelque soit votre occupation:
quel est le pouvoir de mes clients, de mon employeur, de mon manager… ?
quel nouveau venu pourrait prendre mon job ?
quel est le pouvoir de négociation de mes fournisseurs sur le projet, quel est celui des membres de mon équipe ?
existe-t-il d’autres solutions de substitution à ma contribution pour l’entreprise? Ma fonction pourrait-elle être externalisée ou sous-traitée ? Un nouveau « business model » pourrait-il rendre mes services inutiles ou totalement dépassés ?
au sein de l’entreprise ou de l’organisation, quel autre chef de projet pourrait aisément, voire avantageusement, me remplacer ? Certains se seraient-ils déjà positionnés pour reprendre mon job ?
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles