articles, méthodes, partages d'expérience et rdv du management de projets et de l'agilité
Les principes positifs dans le paradigme de l’open source sont nombreux et pas limités au monde du logiciel informatique. Aussi, même pour les personnes n’ayant aucune connaissance préalable du logiciel libre ou gratuit comprendront les analogies et exemples choisis.
La Gestion de Projets et Portefeuille By IQar, découvrez la plateforme de Maturité en Projets !
Nouveauté 2017/2018 : L’outil PPM d’IQar, SuiteProG : un pilotage pragmatique, simple d’accès et pédagogique !
Pour en savoir plus, demandez-nous une démonstration personnalisée de SuiteProG : cliquez ici.
Évaluez la maturité ’Projets’ de votre Organisation : Faites les tests ! 
Et appuyez-vous sur le référentiel français SMPP, le métier et les conseils d’IQar pour décliner cette maturité en plan de progrèsIQar, auteur du référentiel français du système de management des portefeuilles de projets (SMPP), met à disposition des organisations, une plateforme d’information sur l’évaluation et le développement de la maturité en management des portefeuilles projets.
https://www.scrum.org/resources/blog/best-laid-plans-often-go-awry par John Gillespie
Quand Henry Ford a conçu ses usines en 1913 pour construire la Modèle T, il a réduit le temps nécessaire pour assembler une voiture de plus de 12 heures à 2 heures 30 minutes. Ce processus a permis la production d’une automobile à prix ciblé pour “le travailleur”. Toutes les voitures avaient la même conception et toutes étaient peintes en noir.
Les designs préconfigurés fonctionnent quand les prévisions rencontrent les attentes (qui en 1913 aurait demandé une voiture rouge ?) et quand un spécialiste peut remettre son travail au suivant sans aucune perte de temps dans la transmission.
Quand une société est dans le business de produire des produits et des services innovants, ses plans reposent sur une ou plusieurs estimations et suppositions. Ces évaluations ne sont rien de plus que des probabilités. Baser un plan de projet sur des suppositions exige que votre système puisse manager les changements.
Marie Poppendieck a exposé dans Lean Software Development, An Agile Toolkit, “le simple fait mathématique ici au travail est que toute variation est toujours amplifiée comme elle déplace le long d’une chaîne d’événements connectés. Une petite variation dans une étape peut représenter une énorme variation cinq étapes plus loin”. Donc la question reste entière quant à pourquoi les managers continuent à planifier des projets en se basant sur des suppositions séquentielles.
Pour comprendre comment un changement inattendu peut causer des retards significatifs en aval, visualisez une chaussée très occupée avec des voitures se déplaçant selon la limitation de vitesse. Le trafic s’écoule régulièrement jusqu’à l’entrée d’un nouveau véhicule ou autre événement qui fasse qu’un conducteur actionne ses freins. Le trafic sur la chaussée ralentit ou s’arrête alors pendant une brève période puis recommence à s’écouler de nouveau sans signe apparent de pourquoi il a ralenti en premier lieu. L’exemple de cette route illustre comment, à moins que les systèmes ne soient conçus pour se concentrer sur le flux, ils ne fonctionneront pas efficacement à pleine capacité. Parce que le développement de logiciel est un effort complexe dans lequel les suppositions et les décisions devraient être prises le plus tard possible. Le fait de prendre des décisions au dernier moment possible permet à l’équipe Scrum de changer pour travailler sur les articles d’arriéré de produit de plus de valeur en fonction des données les plus récentes.
Par exemple, considérez cinq tâches tout d’une probabilité de 90 % d’achèvement en une semaine: (0.9 * 0.9 * 0.9 * 0.9 * 0.9 = 0.59). Dans ce cas, nous avons cinq tâches sur lesquelles nous nous sentons confiants, mais le résultat cumulatif est que nous sommes à seulement 59 % de probabilité de finir ces cinq tâches en cinq semaines. Je soutiendrais que basé sur mon expérience de professionnel en management de projet, il est aussi peu probable que cinq tâches séquentielles atteignent jamais chacune un niveau de confiance de 90 %. Alors, êtes-vous encore étonné quand vous lisez Standish Group’s Chaos Report qui indique qu’approximativement 70 % de tous les projets des technologies de l’information échouent à atteindre leurs objectifs et sont significativement en retard et sur-dépensent ?
Ceci n’empêche pas que vous devriez adorer les statistiques 🙂
La meilleure façon d’optimiser la livraison de valeur est de faire des tâches ajoutant une valeur visible pour les parties prenantes. La documentation de chaque flux de valeur mettra en évidence l’avancée et les retards entre les transitions. En évaluant quantitativement des activités du flux de valeur, le coût des retards devient aussi visible. Cette visibilité aidera l’organisation à déterminer où la constitution d’équipes fonctionnelles transverses améliorera immédiatement les temps de réponse.
Le leadership a-t-il le désir et l’engagement d’effectuer le changement ? Craig Larman, l’auteur des Laws of Organizational Behavior, a observé que les organisations sont implicitement optimisées pour éviter de changer les positions de statu quo et les structures de pouvoir. Il a aussi noté que si vous voulez changer la culture d’une société, vous devrez changer la structure de votre organisation parce que la culture/comportement et la mentalité suivent les systèmes organisationnels et leur design.
Les organisations comme des sociétés d’assurance et banques ont typiquement les silos de spécialisation fortifiés autour des applications, technologies et fonctions. Chacun de ces départements a développé des règles soigneusement travaillées et des procédures interdisant le changement. Ces processus administratifs ont pour conséquence fortuite de perturber le flux de valeur qui va du concept à la livraison au client.
Marie Poppendieck a décrit cette situation Lean Software Development: An Agile Toolkit, “la règle établie pour résoudre un problème renforcera souvent le problème, créant une spirale vers le bas : Comme un problème empire, les managers appliquent encore plus agressivement la même politique qui cause le problème.” La mise en place d’équipes fonctionnelles transverses qui ont toutes les compétences pour achever le travail sans avoir à traverser des silos fonctionnels aura un impact étonnamment positif sur la capacité des organisations d’améliorer la qualité et le temps nécessaire pour commercialiser.
La plupart des sociétés considérant l’adoption de Scrum devront changer leurs structures organisationnelles pour soutenir des équipes fonctionnelles et transverses autonomes. Si la structure organisationnelle ne change pas, les comportements ne vont pas probablement changer. Si votre modèle business dépend de l’innovation, ce changement devrait être d’une priorité supérieure.
Avec le mode projet, la hiérarchie s’estompe et les équipes doivent apprendre à collaborer efficacement pour aller au bout de leur mission.
Le logiciel Entr’UP Teams qui améliore la collaboration des équipes, leur cohésion et leur efficacité, à travers la maîtrise des interactions est utilisé par de nombreuses équipes. Entr’UP recrute pour participer à un atelier des chefs de projet, directeurs de projets qui vont évaluer les futures fonctionnalités de Smart Assistant, Entr’UP Teams.
https://kbondale.wordpress.com/2017/01/08/dos-and-donts-for-delivering-demos/ par Kiron Bondale
Les démonstrations ou « showcase » comme elles sont parfois appelées, sont des cérémonies critiques quand elle sont menées efficacement car elles adressent des objectifs multiples du projet en un événement simple incluant :
Valider que ce que l’équipe a achevé jusqu’à présent est de valeur de la perspective de leur client et d’autres parties prenantes importantesMais les démonstrations peuvent (comme d’autres pratiques de management de projet) aboutir à un résultat pire que si elles avaient été omises.
A faire : Envoyez les invitations pour la rencontre à l’avance et si vous suivez une cadence de sprint ou d’itération standard (par exemple toutes les deux ou trois semaines). Envoyez un jeu d’invitations récurrentes.Bien que cet article soit principalement destiné aux équipes qui utilisent une approche de développement Agile, il est également applicable aux projets traditionnels. Les démonstrations éblouissantes peuvent aider à maintenir l’attention, conserver l’appui de votre client et maintenir les membres de l’équipe concentrés sur délivrer de la valeur.
Selon Serhiy Kharytonov, le choix entre les méthodes « en cascade », RUP (rational unified process) et agile, dépend à la fois de l’expérience de l’équipe, de la culture d’entreprise, du type de projet, de l’environnement, du mode de développement interne/externe, et prend en compte la dispersion géographique de l’équipe.
Une combinaison des trois méthodes selon les moments du cycle de développement pourrait être une bonne approche.
Cet article qui date pourtant de presque dix ans reste étonnamment actuel.
Article original de Serhiy Kharytonov, SoftServe © 2009
Rationalisez la production avec les processus rapides et efficaces « en cascade », RUP et Agiles. Créez le bon mix de stratégies de développement logiciel afin de répondre aux besoins spécifiques de votre projet.
Pour atteindre ces objectifs apparemment contradictoires, les développeurs cherchent à rationaliser la production avec des processus rapides et efficaces qui peuvent donner au client ce qu’il veut en un laps de temps le plus court possible.
Ces constantes et les échecs de développement passés ont mené à un changement dans le développement logiciel depuis des méthodes très structurées, séquentielles de développement logiciel souvent appelées le modèle Waterfall / « en cascade », vers des modèles plus itératifs et progressifs tels que « Rational Unified Process » et « Agile. »
Les partisans d’Agile sont nombreux et il peut parfois sembler que les processus de développement plus traditionnels sont tombés en défaveur, mais en réalité les trois modèles ont leurs avantages, leurs incovénients et leurs environnements de projet favoris.
Au bout du compte, la meilleure méthode ou le meilleur mix de méthodes pour vous dépend d’une compréhension minutieuse des trois processus et comment ils s’adaptent à votre projet logiciel, votre culture business et votre propre environnement de développement.
La programmation « en cascade » est un processus fortement structuré qui compte fortement sur une planification initiale et un ensemble d’étapes séquentielles, prescrites qui découlent l’une de l’autre comme l’eau dans une une cascade. Chaque étape a typiquement sa propre équipe d’experts et jalons soigneusement préparés à l’avance et aucune étape ne peut commencer tant que l’étape précédente n’a pas été complétée. Le but est de recueillir tous vos besoins détaillés tôt dans le processus et de fournir une seule solution complète avec des résultats qui sont fortement prévisibles. On appelle aussi souvent cette approche le cycle en « V ».
Ceci peut marcher très bien pour des applications complexes, critiques à la mission de l’entreprise et qui s’intègrent avec de nombreux autres systèmes ou pour des organisations comme la NASA ou l’armée qui exigent les plus hauts niveaux de fiabilité.
Les détracteurs disent que le « Waterfall » demande simplement trop longtemps et manque de la flexibilité, ou de l’agilité, requise pour le marché logiciel actuel avec son environnement de développement en constant mouvement. Les projets qui suivent la méthode « en cascade » prennent typiquement des mois ou des années et quand ils sont finis, on découvre parfois que les besoins ont changé ou que les besoins originaux étaient incorrects depuis le départ. Le résultat peut alors être des corrections onéreuses explosant le budget initial.
Comme la « cascade », le Rational Unified Process (RUP), produit par Rational Software et plus tard par IBM, est aussi un processus lourd, mais c’est une approche itérative qui prend en compte le besoin de répondre au changement et introduit de l’adaptabilité pendant le processus de développement.
RUP définit en détail les rôles et les activités de membres de l’équipe et compte à chaque étape sur la production de modèles visuels, qui sont les représentations graphiques riches de systèmes logiciels et des cas d’utilisation spécifiques plutôt que de grandes quantités de documentations requises pour chaque étape « Waterfall ». Tous les membres de l’équipe ont accès à la même grande base de connaissance de guides, modèles, outils et autres articles pour s’assurer qu’ils partagent les mêmes langages et perspectives sur le projet.
Alors que cela apparaît de prime abord similaire au développement « en cascade », la plus grande différence du RUP est son approche de développement itérative, qui construit le produit en plusieurs étapes basées sur des revues fréquentes avec les parties prenantes. Les premières itérations RUP sont surtout de la définition de besoin, de l’architecture et l’exploration de différentes idées, alors que les itérations ultérieures essayent d’assembler un produit complet. Chaque itération est un livrable exécutable et chaque phase RUP peut interagir avec les phases précédentes pour s’adapter au besoin.
RUP adresse bon nombre des critiques du développement « Waterfall » et c’est une bonne méthode pour des agences gouvernementales et institutions éducatives qui apprécient un cycle de développement de logiciel stable et répétable, ainsi que pour des organisations qui « offshore » les développements dans des pays comme l’Inde et la Chine, ou qui produisent des progiciels.
Les critiques disent que RUP n’est pourtant pas aussi rapide ni adaptable que d’autres méthodes, comme Agile et ne marche pas bien quand un délai de mise sur le marché rapide est crucial et là où l’on s’attend à des mises à jour fréquentes et des compléments rapides de fonctionnalités.
Tandis que « Waterfall » et RUP penchent vers la prédictibilité, les buts principaux d’Agile sont la vitesse et l’adaptabilité. Il y a beaucoup de types différents de processus de développement Agile, dont XP et SCRUM, et tous s’efforcent de mettre une version du produit basique mais fonctionnelle entre les mains du client aussi vite que possible.
Ils font alors suivre cette version par des versions successives qui ajoutent et changent les fonctions nécessaires au fil du temps pour fournir un produit plus robuste. Chaque module successif est planifié, codé, testé et complété sur de courtes périodes de deux à quatre semaines. Bien que le processus Agile soit planifié d’avance comme en « Waterfall » et RUP, il fait passer les gens et la collaboration avant le processus lui-même.
Plutôt que de dépendre d’équipes composées de nombreux experts, le processus de développement Agile est typiquement entrepris par une seule, petite équipe, cross-fonctionnelle, censément auto-organisée, qui doit inclure un représentant client qui suit des réunions quotidiennes et s’assure que l’équipe travaille sur les choses dont le business a vraiment besoin. La constante collaboration en face à face est l’objectif, avec le représentant du client comme l’un des collaborateurs les plus importants. La documentation est dé-priorisée par rapport à l’approche « Waterfall » et même RUP pour sortir quelque chose aussi rapidement que possible.
Avec son approche modulaire, progressive, faite en collaboration, Agile est rapide et fortement adaptative au changement des besoins et réponses aux challenges amenés par la compétition, qui sont les raisons de tant de partisans.Certaines sociétés sont fréquemment citées comme ayant utilisé la programmation Agile avec beaucoup de succès, avec des cycles de développement de 30 à 90 jours qui ont apporté une productivité spectaculaire et des avantages business par rapport aux 18 mois ou plus pris dans le passé pour produire un logiciel utilisable.
Mais même s’il est facile de tomber amoureux d’Agile, l’approche a aussi ses limitations et inconvénients. Son accent sur les réunions quotidiennes en physique et la collaboration rapprochée rend le processus difficile à adapter à l’externalisation des développements, à des situations où clients et développeurs sont géographiquement éloignés, ou aux clients qui n’ont tout simplement pas les compétences, les ressources ou le focus nécessaires.
Son accent sur la modularité, le développement progressif et l’adaptabilité ne convient pas aux clients qui veulent des contrats avec des évaluations fermes et définitives et des échéanciers fixes. Sa dépendance sur de petites équipes auto-organisées rend difficile l’adaptation aux grands projets logiciels avec de très nombreuses parties prenantes aux besoins différents et néglige de prendre en compte le besoin de leadership pendant que les membres de l’équipe s’habituent à travailler ensemble.
De plus, le manque de documentation complète peut rendre la maintenance et les nouveaux développements difficiles quand les membres de l’équipe originale laissent leur place à d’autres. Cela peut mener à des modules aux fonctionnalités et interfaces inconsistantes. Finalement, plus qu’avec le « Waterfall » et RUP, le développement Agile dépend éminemment de la capacité à recruter des analystes fonctionnels très expérimentés qui savent comment travailler indépendamment et s’interfacer efficacement avec des utilisateurs métiers.
Si Agile, RUP et des modèles « en cascade » ont chacun leurs inconvénients, lequel devriez-vous choisir ? De plus en plus, le secret des développements logiciels réussis est de comprendre les trois processus dans le détail et de sélectionner les parties de chacun qui conviennent le mieux à leurs livrables et environnements spécifiques. Donc, être agile dans l’approche même du choix du processus, en regardant sans cesse ce qui a été réalisé, en réévaluant et révisant le processus de développement jusqu’à ce qu’il s’adapte au mieux aux circonstances actuelles.
Par exemple, si vous développez du logiciel « Software as a Service » SaaS dans un marché fortement concurrentiel, vous ferez probablement le meilleur choix en penchant vers des méthodologies Agile. Le SaaS se prête particulièrement bien à Agile puisqu’il prévoit un accès constant au logiciel pour y ajouter ou en changer des caractéristiques. Dans un tel marché concurrentiel avec des besoins utilisateurs changeants, vous voudrez probablement être capables d’apporter rapidement des changements.
D’un autre coté, si vous produisez pour le médical, l’ingénierie, ou autres systèmes qui exigent un haut degré de design et de certitude, alors il semble logique de commencer par du »Waterfall ».
Si vous produisez un progiciel grand public « sur étagère », avec de nouvelles versions qui vont être des enrichissements des versions précédentes, votre processus devrait probablement pencher vers RUP, avec une attention particulière sur le recueil des besoins, la définition du périmètre et du contenu au tout début, ainsi que des standards de parcours et d’interface utilisateur.
Les développeurs peuvent tout de même utiliser des techniques Agile pour présenter des prototypes fréquents et des modules successifs aux chefs de produit de la société pour s’assurer qu’ils sont sur la bonne voie. La fréquence et l’intensité de collaboration entre chefs de produit et développeurs dépendent vraiment de leur proximité et de la culture de la société (selon que ces équipes soient plus ou moins habituées à une telle collaboration). Quand la distance géographique est un problème, les outils de collaboration comme la conférence à plusieurs sur le web et la vidéo peuvent être d’une grande aide.
Ce même mélange de techniques peut être utilisé dans un environnement d’externalisation du développement en « offshore ». En fait, avec les différences de fuseaux horaires et de cultures, il est important d’intégrer autant d’étapes itératives et progressives et autant de contacts de suivi que possible pour votre projet.
Choisir de partir sur des équipes auto-organisées ou une approche plus directive (« top-down ») de management dépend aussi du niveau de compétence et d’expérience de vos développeurs. Beaucoup de projets peuvent exiger au départ un leadership qui va ajouter une certaine urgence, une direction et une gestion des risques du projet jusqu’à ce que les membres de l’équipe s’habituent à travailler ensemble. Alors le rôle de leadership peut être réduit selon les besoins lors des itérations suivantes.
Le bilan est qu’il n’y a probablement aucun processus parfait pour tous les projets et tous les environnements, ni même pour un seul.C’est pourquoi les sociétés doivent intégrer fréquemment « les leçons apprises » pour évaluer et réviser le processus lui-même, qui peut se déplacer d’un bout à l’autre du spectre à différents moments dans le cycle de développement.
http://www.jrothman.com/mpd/agile/2016/11/iterations-and-increments/ par Johanna Rothman
Agile, c’est le développement itératif et progressif et la livraison fréquente avec un changement culturel vers la transparence.
Itératif signifie que nous prenons « un morceau à la fois » pour créer une fonction entière. Des approches itératives gèrent le risque technique. Nous apprenons du risque comme nous réitérons à travers le jeu entier des fonctionnalités.
Progressif signifie que nous livrons des portions de valeur. Les approches progressives managent le risque de planification, parce que nous délivrons un travail fini à chaque étape.
Agile fonctionne parce que nous manageons les risques techniques et ceux de planification. Nous réitérons sur un jeu de fonctionnalités, livrant de gros incréments de valeur. (Une raison pour livrer de la valeur souvent et que nous pouvons ainsi changer ce que l’équipe va faire ensuite).
Personne ne veut avoir à s’identifier pour se connecter. Mais, les gens veulent avoir une forte sécurité pour leur paiement. Hors, l’établissement d’une connexion sûre peut être une façon d’arriver à garantir le paiement. Le thème, ou ce que j’appelle un jeu de fonctionnalités, est “l’établissement de la connexion sécurisée”. Un jeu de fonctionnalités, ce sont plusieurs fonctions reliées qui livrent un thème.
Si vous mettez en œuvre la première histoire, vous pouvez utiliser un fichier à plat. Vous pouvez toujours utiliser un fichier à plat pour la deuxième histoire. Une fois que vous commencez à ajouter plus de 10 utilisateurs, vous pourriez vouloir passer à une sorte de base de données. Ce serait une autre histoire utilisateur. Ce n’est pas “Créer une base de données.” L’histoire serait “Explorer des options pour permettre d’ajouter 10, 100, 1000, 10000 utilisateurs à notre site et voir quelles sont les implications en matière de performance et de fiabilité.”
Remarquez « explorer » comme une partie de l’histoire. Cela pousserait à produire des options que l’équipe puisse discuter avec le Product Owner. Certaines options ont des implications à l’exécution.
Chaque fois l’équipe réitère sur le jeu de fonctionnalités, elle livre un incrément. Puisque beaucoup d’équipes utilisent des durées de temps fixes (timebox), elles utilisent « des itérations » comme leur timebox. (Si vous utilisez Scrum, vous utilisez des sprints.) Remarquez les mots “réitère sur le jeu de fonctionnalités.”
Dans des cycles de vie progressifs, comme la livraison par étapes, l’équipe finirait toutes les fonctionnalités dans un jeu de fonctionnalités donné. Les cycles de vie incrémentaux n’ont pas nécessairement à utiliser des timeboxes pour livrer leur développement progressif. Dans les cycles de vie itératifs, comme spiral ou RUP, l’équipe développerait des prototypes de fonctionnalités, ou même finirait partiellement des fonctionnalités, mais l’intégration finale et les tests n’arrivent qu’après que tout le développement itératif ait été fait.
Si vous ne finissez pas vos histoires, vous êtes dans un cycle de vie itératif. Si vous ne limitez pas les fonctionnalités que vous finissez et ne les terminez pas « toutes », vous êtes dans un cycle de vie progressif.
Il n’y a pas de bonne façon de choisir un cycle de vie pour votre projet. Si vous voulez utiliser agile, vous réitérez sur un jeu de fonctionnalités sur un bref cycle de temps, livrant de gros incréments de valeur.
http://kellyprojectsolutions.com/benefits-traditional-waterfall-project-management par Technology Advice
L’approche « en cascade » d’analyse et de conception des systèmes a été créée dans les années 1970 et a gagné la popularité à cause de sa progression logique, linéaire. Les tâches sont décomposées en cinq parties qui suivent une progression ordonnée : définition des exigences, conception, mise en œuvre, vérification et maintenance. Dans la phase de définition des exigences, les programmeurs et le client déterminent le périmètre du projet; dans la phase de conception, les programmeurs créent des designs ou maquettes basiques et complexes; dans la phase de mise en œuvre, les programmeurs testent le code source comme le programme est écrit; dans la phase de vérification, les programmeurs évaluent la conception et corrigent les erreurs; et dans la phase de maintenance, les programmeurs apportent les changements nécessaires pour assurer que le système continue de fonctionner correctement. Chaque phase doit être soigneusement planifiée à l’avance pour assurer le succès.
Aujourd’hui, beaucoup de business optent au lieu de cela pour la gestion de projet Agile. Les personnes qui utilisent cette méthode se concentrent sur la production de petites parties du projet dans chaque cycle de livraison, plutôt que la création d’un plan pour le projet entier.
Selon Techrepublic.com “l’accent sur les exigences et la conception avant l’écriture d’une seule ligne de code assure un gaspillage minimal de temps et d’effort et réduit le risque de dérapage de délais, ou d’attentes de client non atteintes.” Parce que les promoteurs et des clients discutent des objectifs finaux dans le détail, les deux parties ont une solide compréhension des attentes primaires et des résultats désirables. En conséquence, il est beaucoup plus facile de garantir que le projet est sur la bonne voie.
Les programmeurs développent seulement le code qui est en réalité nécessaire, ce qui sauve temps et effort pendant les étapes initiales. Les développeurs peuvent corriger n’importe quelles erreurs ou défauts tôt dans le processus, ce qui permet à la phase de mise en œuvre de se dérouler sans à-coup. Parce que l’objectif final est clairement défini dans les étapes de démarrage, toutes les parties comprennent les contraintes de temps et de finances du projet. Dans son livre paru en 1996 Rapid Development: Taming Wild Software Schedules Steve McConnell a évalué que “un défaut d’exigences qui reste non détecté jusqu’à la construction ou la maintenance coûte 50 à 200 fois autant pour le fixer qu’il n’aurait coûté au moment de la définition des exigences.” En conséquence, achever chaque cycle avant de passer au suivant garantie le succès au final.
Parce que le projet est clairement planifié du début à sa fin, les travailleurs peuvent rapidement mesurer leurs accomplissements et livrables. La méthode en cascade est idéale pour les équipes qui travaillent étroitement ensemble, puisqu’elle offre des tâches et des objectifs précis. Elle permet aussi aux développeurs de continuer à travailler sur le projet sans avoir besoin de la surveillance constante d’un manager.
Le logiciel peut être conçu en se basant sur une compréhension minutieuse des éléments à fournir.Parce que la méthode traditionnelle entraîne une documentation minutieuse, les programmeurs peuvent garantir qu’ils répondent aux attentes des client avant que le projet ne soit achevé.
Dans la phase de maintenance, les programmeurs et clients peuvent observer la solution pour déterminer si elle fonctionne correctement. S’il y a des problèmes, les programmeurs peuvent corriger les erreurs avant la remise du produit fini aux clients.
Bien que moins flexible que la gestion Agile, la méthode en cascade fournit un plan clair de résultats attendus tant pour les programmeurs que pour les clients. Elle peut faire gagner du temps et de l’argent en offrant une stratégie bien définie. Ce n’est pas la méthode la plus populaire actuellement, mais c’est un système valable et qui peut être mis en œuvre avec presque n’importe quel logiciel de management de projet. Les sociétés et leurs clients devraient considérer les bénéfices de la méthode de management de projet en cascade traditionnelle.
Les dernières versions de MS Projet permettent de mettre en place très rapidement un projet simple à partir de modèles préremplis et de la planification automatique. Celle-ci permet d’insérer des tâches dans une chronologie d’un simple clic de souris.
Une troisième vidéo humoristique de notre partenaire Microsoft qui met en évidence certains des avantages à quitter Excel pour un outil dédié au management de projet.
Faire des rapports et prendre des décisions sur votre projet est bien plus aisé avec Project qu’avec Excel. Une seconde vidéo humoristique de notre partenaire Microsoft qui met en évidence certains des avantages à quitter Excel pour un outil dédié au management de projet.
Une première vidéo humoristique de notre partenaire Microsoft 🙂 . Elle met en évidence certains des avantages à quitter Excel pour un outil dédié au management de projet et donc bien plus puissant tout en restant simple. En effet, Project permet d’opter pour une planification totalement manuelle si nous le souhaitons.
En analysant de plus près nos méthodes de développement, maturité des équipes et autres facteurs, le rapport CRASH nous confirme que nous sommes sur la bonne voie même s’il reste encore des choses à améliorer. Nos pratiques de développement et de livraison de nos projets informatiques et technologiques évoluent positivement !
Vous pouvez télécharger le rapport complet ici.
Avant que la Collaboration Sociale ne fasse son apparition, le quotidien d’un chef de projet était accaparé par les voyages et les appels téléphoniques afin de coordonner les membres de son équipe et de piloter son projet. Aujourd’hui, les choses ont bien changé.
Cette nouvelle édition du livre blanc raconte de manière ludique la journée d’un chef de projet du XXIe siècle, utilisant toutes les technologies Microsoft pour mieux organiser son travail quotidien et ses projets : Office 365, Delve, Project Online, SharePoint, Skype for Business, Yammer ou encore Office Groups, Planner et Wunderlist.
Télécharger le livre blanc (3.3 M)
Beaucoup d’attention est portée au « Manifeste Agile » et bien qu’il soit une composante importante de Agile, ce n’en est pas toute la substance. Il y a 12 principes directeurs en plus des 4 composants principaux du manifeste. Jetons un rapide coup d’œil à chacun d’entre eux et voyons combien ils affectent comment nous percevons et implémentons les pratiques Agiles…
Ceci est l’aspect le plus important d’Agile qui doit être compris et adopté comme une partie de la culture de toute organisation qui veut être « Agile » : le client et l’utilisateur final sont le focus ultime du processus tout entier, du commencement jusqu’à la fin. Le client est le juge du succès ou de l’échec d’un produit ou d’une fonctionnalité, pas la société ni ses parties prenantes. Le client est celui avec les problèmes que nous adressons et comme tel il doit être partie intégrante du processus de développement de produit du commencement à la livraison.
Ignorer vos clients jusqu’à ce que votre produit soit prêt à être expédié est l’anti-modèle Agile numéro 1 dans le monde.
La deuxième partie la plus importante de Agile est en fait… …de faire preuve d’agilité. N’importe quelle organisation qui investit lourdement dans la définition en amont, la conception et la définition des besoins n’est Pas Agile…et ne fait certainement pas preuve d’agilité. Tout le point de l’agilité est que vous pouvez vous accommoder d’importants changements de besoins à n’importe quel point du processus et toujours livrer quelque chose qui est utile pour le client et résout un ou plusieurs de leurs problèmes. Des processus agiles s’appuient sur la Priorisation et non par la Négociation de contrat pour atteindre le succès. Quand de nouveaux besoins surviennent, ils ne sont pas soumis à de lourds et détaillés processus de management des changements. Ils sont plutôt ajoutés à la pile de tout le reste à faire et évalués tout simplement comme une autre tâche ou histoire utilisateur déjà dans le processus.
Penser que les choses sont totalement ou presque entièrement définies à l’avance est un autre anti-modèle Agile dont beaucoup de sociétés souffrent fréquemment.
Il y a plusieurs choses dans ce principe. D’abord du logiciel qui marche est le but du processus à chaque étape, ensuite le travail devrait être itératif et s’améliorer à chaque livraison et, finalement les itérations qui sont engagées devraient être les plus courtes possible. Si vous travaillez sur un projet qui progresse pendant six mois sans vérifier les résultats intermédiaires avec le client (ou son représentant), vous n’êtes pas Agiles. Si vous travaillez sur des itérations d’une semaine, mais ne livrez pas quelque chose qui résout au moins un problème client à chaque itération, vous n’êtes pas Agiles. Les itérations agiles doivent être assez longues pour livrer un logiciel qui fonctionne et assez courtes pour vous assurer que ce que vous livrez résout bien dans les faits des problèmes clients.
Travailler itérativement ne signifie pas nécessairement que vous êtes Agiles; l’itération est importante, mais livrer un logiciel qui fonctionne l’est tout autant.
La collaboration et les interactions entre les gens sont critiques au succès de toute organisation Agile. Les silos et le « jeté de besoins par-dessus le mur » sont contre-productifs aux approches Agiles, comme l’est de segmenter votre organisation entre les gens « du métier/business » et les « techniciens ». Tout le monde du côté « métier/business » devrait être prêt, consentant et disponible pour fournir autant de support que possible aux équipes « techniques » et vice versa. L’idée séculaire qu’il y a une certaine différence inhérente entre la façon dont « l’activité business » devrait être exécutée et la façon dont « la technologie » devrait l’être est entièrement artificielle et contre-productive dans un âge d’innovation rapide et de livraisons encore plus rapides.
Décourager la collaboration ou encourager le « silotage » des efforts est un anti-modèle Agile qui persiste dans trop de cultures d’entreprise.
Agile valorise les personnes en tant que personnes et les équipes en tant qu’équipes. Les gens ne sont pas des rouages interchangeables que vous pouvez aléatoirement déplacer d’un projet à un autre et vous attendre à ce qu’ils excellent continuellement. Les individus sont motivés par des choses différentes et dans une vraie approche Agile nous exploitons ce qui motive individuellement les membres de notre organisation pour créer des équipes avec ces individus motivés qui sont intrinsèquement motivés pour réussir. Agile déboute de l’idée que la récompense extrinsèque fournit des résultats exceptionnels et se concentre plutôt sur l’assurance que les individus aient la motivation, l’environnement et les outils dont ils ont besoin pour réussir tout seuls. Il n’y a aucune approche de type « la carotte et le bâton » dans Agile. Il y a des problèmes à résoudre pour les clients qui sont intéressants et fascinants et qui sont résolus par des personnes qui ont l’intérêt nécessaire et la motivation intrinsèque pour les résoudre.
Attendre des gens d’être performants simplement parce qu’ils sont membres « d’une équipe » et non pas parce que cette équipe partage la motivation intrinsèque de réussir est un anti-modèle extrêmement commun dans les grandes organisations.
La méthode séculaire d’avoir un unique expert du sujet qui écrit tout qu’il veut avoir et le remet aux développeurs comme « une liste à exécuter » de besoins est hérétique aux approches Agiles. Des personnes différentes pensent et communiquent différemment et le texte écrit est l’une des pires façons d’exprimer que vous essayez de dire. Au pis-aller, c’est vague et difficile à déchiffrer pour la personne qui ne l’a pas écrit; au mieux, c’est un document clinique, stérile qui remplace le sentiment par la précision. Si le but est d’exprimer la douleur que ressent le client et motiver les équipes à exceller dans leur job parce qu’elles le veulent, alors aucune de ces approches par des besoins écrits n’aura le résultat que nous désirons. Nous utilisons plutôt des choses comme les Histoires Utilisateur, qui explicitent le problème que nous voudrions résoudre, mais qui permettent à notre équipe de développement d’utiliser sa créativité pour y répondre de la meilleure façon possible.
Même quand nous utilisons des outils pour suivre le travail et communiquer les informations les plus basiques, nous ne pouvons pas oublier que la façon la plus importante de communiquer l’un avec l’autre, indépendamment des rôles, est toujours la conversation en face à face.
Particulièrement dans le monde des grandes sociétés, nous aimons le concept que tout peut être mesuré, évalué et KPIsé. Nous suivons les revenus, des points d’histoire, la vélocité, la consommation, les nombres d’erreurs découvertes, Ad Nauseum. Pourtant nous oublions souvent que ce que nous essayons vraiment de faire est résoudre des problèmes pour les clients. Et aucune de ces mesures n’indique combien de valeur nous apportons en réalité ni si nous résolvons vraiment des problèmes clients. Le but final de chaque itération devrait être du logiciel qui marche, qui fait quelque chose que nous pensons être de valeur. Sans cela, c’est un échec. Quoi que ce soit de plus que cela est du glaçage sur le gâteau. Les équipes Agile se mesurent elles-mêmes sur si elles apportent réellement de la valeur et si elles créent vraiment quelque chose qui marche la fin de chaque itération.
Répétons ceci : la vélocité n’est pas la mesure du progrès. La consommation n’est pas la mesure de progrès. Les points d’histoire ne sont pas la mesure de progrès. La capacité n’est pas la mesure de progrès. Les délais ne sont pas la mesure de progrès. La seule chose qui importe est combien vous créez de logiciel qui marche.
Il y a cette idée fausse dans le monde, tenue tant par les développeurs que par des hommes d’affaires, que Agile signifie aucune documentation, que Agile veut dire faire quoi que vous ayez besoin de faire pour atteindre un but, que Agile signifie changer les priorités et équipes rapidement pour assurer une production maximale, que Agile rime avec imprévisibilité et manque de prédictibilité. Le fait est, l’un des buts principaux d’Agile est créer un environnement de prévisibilité, de stabilité et une allure constante et acceptable de développement de produits qui dure indéfiniment. Il n’y a rien dans les principes Agile qui écarte de créer des planning (quoique ces plans portent un peu d’incertitude !) ni d’être capable de prévoir quand quelque chose pourrait être livré. Au contraire, il n’y a rien dans les principes Agile qui s’attend à ce que des développeurs s’engagent dans des comportements de pression exagérée. En fait, de tels comportements sont de bien des façons antithétiques aux concepts Agiles : si votre équipe doit travailler beaucoup trop durement pour livrer quelque chose, vous avez manqué en amont à vos devoirs de priorisation efficace des Histoires Utilisateur.
Aucune vraie pratique Agile ne devrait aboutir à de l’épuisement, des périodes critiques, ni une incertitude constante et prolongée. Les anti-modèles aboutissent à ces comportements contradictoires.
Des équipes vraiment agiles ne rassemblent pas à la va vite de mauvais morceaux de code pour l’appeler « bon ». Elles prennent le temps et mettent les efforts nécessaires pour comprendre ce qu’elles essayent de réaliser, comment elles pensent pouvoir résoudre les problèmes et décomposer les choses en assez petits « morceaux » de travail pour à la fois itérer sur le problème et livrer des solutions potentiellement exploitables à chaque étape du projet. La majorité de ce travail se produit avant que les équipes ne s’engagent à faire le travail. Il y a là du pré-travail pour parler approches, pour discuter architecture et s’engager dans des discussions avec des représentants du métier, des parties prenantes et les équipes techniques. Nous nous référons souvent à ceci comme à des sessions de démarrage ou de préparation d’arriéré de produit mais Agile ne devrait jamais être une excuse pour la mauvaise qualité ou une conception erronée.
La conception erronée et de faibles standards aboutissent à de pauvres solutions qui ne répondent pas vraiment aux besoins clients; c’est un facteur de ralentissement, pas un facteur d’accélération.
Beaucoup trop de personnes lisent ceci de la mauvaise façon et limitent ainsi leur capacité à totalement s’engager dans des pratiques Agiles fortes. Simplifier vos buts, vos histoires, votre travail et tout le reste est un processus qui commence par l’opposé : une très large compréhension de ce que sont les buts et de comment ils pourraient être atteints. Le résultat de tels efforts n’est pas nécessairement un projet plus petit, mais des incréments plus petits et plus simples qui peuvent s’additionner en quelque chose de très grand et qui peuvent aussi indirectement réduire les buts globaux. Le plus grand obstacle est ici que le simple est plus difficile que le complexe, particulièrement quand les gens s’engagent dans des séances de remue-méninges, ce qui arrive souvent avec des équipes techniques. Résolvez le problème d’abord, itérez ensuite par petits morceaux.
« Rendez chaque détail parfait et limitez le nombre de détails à perfectionner. » Jack Dorsey
Le mot clé est ici « naissent ». Quand vous réunissez les bonnes personnes et que toutes sont alignées vers les mêmes buts, certaines choses se produisent. D’abord, elles se tiennent naturellement responsables, parce qu’il y a un sentiment intrinsèque de camaraderie et de but commun. Deuxièmement, Elles se supportent et en même temps se défient pour assurer que le résultat final respecte non seulement leurs attentes individuelles, mais aussi leurs attentes collectives qui sont presque toujours plus élevées. Et finalement, elles améliorent le tout par la collaboration : la valeur de n’importe quelle équipe auto-organisée est au moins 2 fois plus importante que la somme de ses parties individuelles. Le facteur clé est ici auto-organisation, qui peut être dure à vendre dans beaucoup d’organisations, mais les meilleures équipes ne sont pas celles assemblées par un cadre intermédiaire, ce sont plutôt des groupes de personnes qui ont choisi de s’aligner vers un but commun.
Les personnes qui travaillent vers un but commun parce qu’elles le veulent seront toujours plus efficaces, plus fortes et plus fiables que des équipes travaillant ensemble parce qu’on leur a dit de le faire.
Dans presque chaque organisation que j’ai observée face au défi d’implémenter les pratiques Agile, la plus grande chose qu’elle loupe est l’importance de l’amélioration continuelle ou continue. Agile a ses origines dans des concepts industriels LEAN : la valeur de l’individu, la primauté du résultat sur le processus et, plus important encore, le besoin de constamment mesurer, ajuster et améliorer comment vous faites ce que vous faites. Toute équipe qui veut ne pas s’engager dans les rétrospectives et les revues d’équipe avec leurs parties prenantes après chaque itération risque la stagnation et les anti-modèles parce qu’elle ne les voit jamais arriver. Beaucoup d’équipes voient ces sessions comme contre-productives, des pertes de temps, des exercices « soft skills » qui consomment seulement de leur temps d’exécution. Mais la plupart des équipes les évitent simplement par crainte (et le rationalisent comme elles le peuvent): la crainte d’être sur la sellette, la crainte d’accepter la responsabilité, la crainte de changement. La vérité vraie est que quand elles sont exécutées correctement, elles peuvent être les réunions les plus enrichissantes dans lesquelles les équipes s’engageront. Elles sont destinées à pousser les gens à constamment s’améliorer et être plus efficaces et il n’y pas de bonne raison de ne pas s’engager dans ces discussions.
L’absence de « regarder derrière soi » profondément et honnêtement pour évaluer comment une équipe avance et où elle peut s’améliorer est un anti-modèle fatal au succès de Agile sur le long terme.
Nous nous endettons pour nos voitures, nos maisons, et grâce aux cartes de crédit nous nous endettons même pour l’épicerie et l’essence.
Dans le développement logiciel, comme dans la vie, avoir un peu de dette peut en réalité être une bonne chose pour faire progresser les choses les plus critiques. Bien que dans des blogs précédents nous ayons défini la dette technique comme « le coût pour réparer des problèmes de qualité structurels d’une application qui, si laissés défectueux, pourraient mettre le business en danger », engager un montant faible et raisonnable de dette technique peut en réalité faire avancer le projet plus rapidement et permettre d’atteindre l’objectif d’avoir un logiciel utilisable. C’était la pensée de Ward Cunningham, le créateur du concept de dette technique.
Mais comme Derek Huether l’indique dans son blog de conseils technologiques pour le Dumas Lab à propos de la dette technique : « Comme toute dette dans la vie de tous les jours, vous vous trouverez tôt ou tard devant le besoin de la rembourser. »
Derek remarque aussi que tout comme toute dette dans nos vies personnelles, si non remboursée, d’une façon ou d’une autre : Elle reviendra pour vous hanter. Si votre bidouille d’une solution ne revient pas mordre l’équipe de développement, elle hantera probablement l’équipe de support technique ou quelqu’un d’autre en aval.
Comme toue dette, vous vous retrouvez devant le besoin de la rembourser tôt ou tard …, j’ai vu (et vois) ce que la dette technique peut faire à la vélocité d’une équipe. Elle les prive d’un temps précieux, après coup. L’équipe de développement achète l’idée que faire des choses de la mauvaise manière, qui peut sauver un peu de temps dans l’immédiat, vaut les risques et le coût total. C’est vraiment une vue à court terme du processus de réflexion. La dette technique ressemble à l’obtention d’un prêt d’un usurier qui jetterait les dés pour décider de votre taux d’intérêt. Alors, si vous n’êtes pas obligés de prendre ce risque, ne le prenez pas.
Mais la dette technique est-elle vraiment une proposition de type tout ou rien, blanc ou noir ?
Quand elle considère la Dette Technique, une société doit déterminer combien devrait être investit pour y remédier. La meilleure façon de le faire est en donnant une valeur monétaire à la dette technique pour allouer une valeur financière à la qualité structurelle de l’application. Cela permet de comparer les coûts informatiques à rembourser cette dette par rapport aux pertes potentielles coté business en raison d’un échec qui n’était pas envisageable avant de contracter cette dette.
Le but de monétiser la dette technique est de limiter le nombre de violations de la qualité structurelle, ou ce qui est plus important, le coût de les réparer, bien en dessous du coût que la société encourrait si le logiciel devait être déployé et aboutir à un échec.
Pour déterminer le point de basculement des problèmes de qualité structurelle et du coût pour les réparer, une société devrait utiliser une plate-forme d’analyse et de mesure automatisée pour évaluer la qualité structurelle de leurs cinq applications les plus cruciales à la mission de l’entreprise. La façon dont chacune de ces applications est construite, leur qualité structurelle devrait être mesurée à chaque version majeure et une fois qu’elles fonctionnent, la qualité structurelle de l’application devrait être mesurée chaque trimestre.
La clé est de garder un œil vigilant sur le compteur des violations; contrôlez les changements et calculez la Dette Technique de l’application après chaque évaluation de qualité. Quand une valorisation monétaire de la dette technique a été vérifiée, elle peut être comparée à la valeur business pour déterminer combien de Dette Technique est trop et combien reste acceptable par rapport au retour marginal sur la valeur business. Pour établir une structure de calcul de la perte de valeur business en raison des violations de qualité structurelles, nous recommandons “The Business Value of Application Internal Quality” par Dr. Bill Curtis.
Une fois que ce point de basculement est déterminé, une société peut décider où et quand elle doit aborder les problèmes de qualité structurelle qui ont généré la dette technique.
La partie agréable de se débarrasser de dette technique est la même que pour la dette personnelle: cela évite de devoir payer plein d’intérêts.
Alors, profitez de cette période un peu plus calme pour entamer ces travaux de remboursement…
Si vous en connaissez d’autres, n’hésitez pas à les ajouter en commentaires à ce billet et je les intègrerai dans la liste.
Voici une page que je n’avais pas visité depuis plusieurs années et qui continue à répondre à de nombreuses premières questions que vous pourriez avoir si vous cherchez à vous doter d’un logiciel de management de projets et/ou programmes.
Rassemblant les résultats de l’analyse de 1300 applications développées par plus de 200 entreprises, cette étude de CAST sur la qualité logicielle des applications (CRASH), présente l’impact objectif des méthodes agiles, de l’externalisation et de l’offshoring.
L’étude traite de la dette technique, des langages de programmation, des tendances en méthodes de développement et de sourcing, et de leur impact sur la qualité de vos applications métiers critiques.
La sortie de Microsoft Project Server 2013 il y a un peu plus de deux ans permettait pour la première fois un accès optimisé aux données projet depuis des appareils mobiles, facilitant ainsi la communication et la collaboration au sein des équipes.
La possibilité d’utiliser l’étendue des fonctionnalités de Microsoft Project Server en tant que service en ligne depuis le cloud avait elle aussi suscité un grand intérêt car elle permettait de simplifier le déploiement de l’outil dans toute l’entreprise, allégeant ainsi la charge du département IT. Bien que la nouvelle version Microsoft Project 2016 semble moins innovante, les apparences sont trompeuses, comme a pu le constater Campana & Schott au cours de ses nombreux tests. Les fonctionnalités étendues de management des ressources ont notamment fait très bonne impression car elles permettent de coordonner une organisation matricielle nettement plus efficacement qu’auparavant. En fonction de la spécialité de chaque entreprise, la mise à niveau avec la nouvelle version promet non seulement un gain de productivité significatif, mais aussi une gestion multi-projets plus souple, ce qui s’accompagne évidemment d’une plus grande réactivité face à la concurrence.
Les versions actuelles de Microsoft Project Server et Project Online offrent d’ores et déjà un aperçu global de l’évolution des projets en cours, depuis différentes perspectives. Les responsables de ressources et supérieurs hiérarchiques peuvent ainsi voir à tout moment sur quels projets leurs ressources sont affectées. Cependant, dans la pratique, ces affectations sont sujettes à de nombreuses modifications : certains employés peuvent subitement ne plus être disponibles pour raison de maladie ou parce qu’ils sont appelés ailleurs pour une urgence. Par conséquent, les chefs de projet sont amenés à replanifier leurs projets et il devient alors difficile pour les supérieures hiérarchiques d’évaluer rapidement et précisément les répercussions possibles de ces modifications sur les autres projets. L’engagement pris lors de l’affectation initiale est alors rompu. De ce fait, les supérieurs hiérarchiques manquent d’une base de décision valide pour accepter ou refuser les nouvelles demandes de projet affectant les membres de leurs équipes. Cette difficulté est principalement due au fait que la précédente version de Microsoft Project Server ne prévoyait aucun process officiel de validation d’affectation de ressources par les responsables hiérarchiques.
Dans la pratique, on trouve des exemples typiques de ce genre de problématiques aussi bien dans les entreprises de services que dans le génie logiciel et l’ingénierie, secteurs dont la croissance est souvent soudaine et qui implique le déploiement rapide de nombreux sites. Il n’y a, dans les premières années, que peu de projets multi-sites : il est alors facile de garder une vue d’ensemble précise de la répartition des tâches parmi les employés. Mais à mesure du développement de l’entreprise et de l’augmentation du nombre de projets, cet aperçu devient de plus en plus compliqué : le personnel d’un site en particulier sera-t-il sur ou sous-occupé le mois suivant ? Où se trouvent les spécialistes les plus compétents pour le prochain projet ? Dès lors, les demandes urgentes de gros clients ne peuvent plus être traitées dans un délai suffisamment court, un inconvénient de taille dans la relation client. Il est en effet impossible de déterminer directement si la commande concernée pourra être prise en charge dans le délai imparti. Dans de tels cas, il devient finalement indispensable de procéder à une optimisation des outils pour le management des ressources. Cet exemple est typique dans la mesure où, souvent, une infrastructure de gestion de projet qui fonctionne bien à la base ne parvient néanmoins pas à tenir le rythme de croissance de l’entreprise sur le long terme.
Par le passé, les utilisateurs de MS Project Server se servaient souvent de solutions complémentaires spécialisées réconciliant les besoins des projets et les engagements des équipes métiers au sein des organisations matricielles. D’autres ont essayé de modéliser la planification des ressources inter-projets au sein de fichiers Excel complexes. Malheureusement, ces solutions sont rarement pérennes et la double saisie engendrée entraîne d’inévitables incohérences. Résultat : davantage de coûts au lieu de davantage de transparence.
La version Microsoft Project Server 2016 offre de nouvelles perspectives dans la gestion des capacités et des ressources. Les nouvelles fonctionnalités « demande de ressources » et « engagement de ressources » remédient en effet au problème décrit plus haut : l’outil historise l’intégralité des accords et refus délivrés par les responsables hiérarchiques vis-à-vis des demandes d’affectations émanant des chefs de projet. Cela crée ainsi un socle solide sur lequel peut se baser la communication entre toutes les parties prenantes – y compris les responsables hiérarchiques.
Il s’agit là d’une fonctionnalité à forte valeur ajoutée pour le métier, attendue depuis longtemps par de nombreux clients de Campana & Schott. La capacité de décision ainsi acquise au niveau du responsable des ressources peut à elle seule générer un gain de productivité d’environ 10 % dans les entreprises de services. Autre avantage : ces fonctionnalités étendues de Microsoft Project Server 2016 en management de ressources sont directement disponibles, aucune configuration additionnelle n’est nécessaire.
Par ailleurs, la nouvelle version Microsoft Project Server 2016 favorise la prise rapide de décisions par le biais des dites « heat maps » – une fonctionnalité qui impliquait par le passé le recours à un partenaire d’implémentation : des graphiques de couleur permettent maintenant d’identifier d’éventuelles ressources en sur-utilisation ou à contrario en sous-utilisation entre différents projets, et ce même avec un important volume de données et des interdépendances extrêmement complexes.
Les cartes utilisent les couleurs des feux tricolores, avec des seuils à définir librement. Cela permet aux supérieurs hiérarchiques d’agir avec un maximum de flexibilité lors de la planification des interventions et de prévenir ainsi des situations d’impasse au niveau d’un projet ou d’une ressource critique.
La fonctionnalité « Timeline » (frise chronologique) permettait déjà dans Project 2013 de visualiser le déroulement du projet le long d’un axe de temps. La version Microsoft Project 2016 propose à présent dans le client riche l’option de gérer plusieurs axes de temps pour un projet et de les afficher sous forme de barres superposées. Par exemple, la barre supérieure peut représenter le projet dans son ensemble, tandis que celle du dessous décrit plus précisément un lot spécifique du projet. Il est ainsi possible de différencier précisément les phases du projet, sans que les détails ne brouillent la vue d’ensemble du projet.
En outre, l’intégration d’une nouvelle fenêtre de recherche directement dans l’interface du client riche réduit considérablement le temps nécessaire pour trouver des fonctions rarement utilisées.
Avec Project 2016, Microsoft poursuit sa route vers le cloud. Bien que Project Online ne soit disponible que depuis le début de la sortie de Project 2013, la plupart des nouveaux clients britanniques par exemple misent sur la version Online, le plus souvent en association avec Office 365. La France en revanche se montre encore hésitante vis-à-vis des solutions cloud et continue de privilégier la version on premise. Toutefois, l’interaction de Project Online avec d’autres offres de Microsoft dans le cloud devient de plus en plus importante en termes de productivité et d’efficacité – par exemple avec SharePoint Online, Power BI, Skype Entreprise Online, Dynamics CRM Online, ou encore avec la plateforme sociale dédiée aux entreprises Yammer, qui fait partie de Microsoft depuis 2012.
D’un point de vue utilisateur, le grand avantage d’une solution cloud comme Project Online est sans doute sa disponibilité immédiate évitant de longs et fastidieux accords avec le département IT. Comme les versions en ligne sont conçues et mises à disposition des utilisateurs de manière incrémentielle, les cycles d’innovation se raccourcissent. Inutile à présent d’attendre la version suivante : les nouvelles fonctionnalités sont immédiatement disponibles et utilisables. Cela réduit considérablement la charge de travail du département IT puisque le portefeuille d’applications gérées en interne n’augmente pas et les contraintes liées à un changement de version n’ont plus lieu d’être. Pour les PME notamment, qui n’utilisaient jusqu’à présent que le client riche en local, Project Online devient une possibilité simple de passer à Project Server, sans nécessiter d’investissements en nouveau matériel. De même, pour les entreprises utilisant à présent Project Server 2003, 2007 ou 2010 qui envisagent une migration, l’option Online mérite d’être étudiée. Microsoft a d’ores et déjà mis un terme au support global pour les versions 2003 et 2007 et le support devrait s’arrêter d’ici la fin de l’année pour Project Server 2010.
Dans les entreprises dotées d’une organisation matricielle, les avancées significatives en termes de management des ressources de Microsoft Project Server 2016 apportent davantage de transparence entre la planification de projet et la planification hiérarchique. L’historisation des validations concernant les demandes d’affectation de ressources permet une meilleure visibilité et communication entre les différentes parties prenantes. Les outils complémentaires pour la planification des ressources tels que les tableurs Excel deviennent ainsi superflus. Par ailleurs, des rapports standards et des « heat maps » intégrés facilitent l’analyse d’éventuelles sur-affectations ou sous-affectations des ressources entre les différents projets de l’entreprise. Dans l’ensemble, la solution avancée de gestion des ressources proposée par Microsoft Project Server 2016 agit comme un important levier pour l’amélioration de la répartition des activités parmi les acteurs projet et donc pour l’augmentation de la productivité de l’entreprise. En effet, plus la part de chiffre d’affaires générée par ressource est élevée, plus l’impact d’une planification optimisée influe sur le résultat commercial. Néanmoins, il ne faut pas oublier qu’un outil de management, aussi performant soit-il, ne portera aucun fruit s’il n’est pas accompagné de procédures, règles et rôles appropriés afin de l’ancrer dans l’organisation.
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)
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.
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).
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.
DantotsuPM.com 