Comment Préparer une Réunion avec son Sponsor de Projet

Article original en anglais: http://www.pmhut.com/how-to-prepare-for-a-project-sponsor-meeting par Zenkara

Les sponsors sont cruciaux dans presque tous les projets. Ce sont les personnes qui font approuver les budgets, qui fournissent l’énergie et l’impulsion pour que le business soit prêt à temps pour le projet.

Pourtant, les Chefs de projet semblent souvent les traiter comme un mal nécessaire et même une distraction du vrai travail de projet. Quand nous rencontrons des sponsors, nous emportons souvent un rapport de progrès/statut de projet et le passons rapidement en revue pendant la réunion. Si nous n’avons pas grand-chose à annoncer, nous tournons souvent les mots dans le rapport pour qu’il semble qu’il y ait une réelle action. Ces types de rapports de progrès ont souvent peu de mesures quantitatives et sont un festival de mots plutôt qu’un vrai compte rendu.

Cependant, quand vous traiterez la rencontre avec le sponsor comme l’opportunité qu’elle représente, vous rencontrerez plus d’engagement et de succès dans vos projets.

Rappelez-vous que les sponsors eux-mêmes reportent d’habitude à quelqu’un (ou à un comité, l’équipe de direction etc) donc il est dans leur intérêt de savoir ce qui se passe vraiment.

Traitez chaque réunion de sponsor comme si vous leur vendiez le projet/livrable et vous verrez bientôt une revitalisation de votre business.

Préparez-vous pour la réunion en recueillant non seulement le compte rendu, mais aussi ce qui n’est pas écrit dans le compte rendu.

Des renseignements sur l’équipe, l’environnement, la politique chez le client, la performance de projet permettent de donner une image beaucoup plus large de ce qui se passe et plus proche de ce que des sponsors veut vraiment savoir.

Ils peuvent toujours lire un rapport d’avancement pour obtenir le pourcentage de complétude, budget dépensé, et risques identifiés. Quelques PMs s’exclameront “mais nous devons expliquer le rapport au sponsor”. Cela indique en fait un rapport mal écrit.

Des sponsors motivés sont tout autant intéressés par ce qui n’est pas dans le rapport et plus important encore si leurs attentes seront toujours satisfaites. Ils veulent aussi s’assurer qu’ils sont au courant de toute surprise aussitôt qu’elle surgit – plutôt qu’être informé en fin de mois.

Un travail important du PM est de manager les attentes – particulièrement celles du client et du sponsor. En parvenant à connaître leurs soucis avant la réunion, vous pouvez commencer à prévoir quelles questions ils poseront pendant la réunion¹.

Bien sûr si vous n’obtenez pourtant rien d’eux :

1. Leurs priorités sont ailleurs et vous devez revenir devant leur yeux pour un résultat réussi – “pas en vue, souvent oublié » ou,
2. Ils sont complétement satisfaits avec l’avancement du projet (moins probable)

Quand vous pouvez prévoir leurs besoins et venir préparé avec des réponses, vous construisez la confiance en leur projet et en votre avancement.

Cela peut sembler être un cliché, mais aider eux vous aident …

Voici une liste de préparatifs pour cette réunion

1les Emails qui vous arrivent du sponsor pendant la semaine sont un bon indicateur de ses préoccupations – bien lire  entre les lignes.

Liste de contrôle Pré réunion avec le Sponsor de Projet

C’est toujours une bonne idée de venir préparé aux réunions avec des sponsors de projet

– Particulièrement si vous avez de mauvaises nouvelles. La chose importante est d’éviter toute surprise.

Quel est l’objectif de la réunion ? Quel résultat voulez-vous atteindre ? Accord, consensus, information ? Quel pourcentage du projet a été réalisé par rapport aux prévisions ? Quels sont les 4 messages clés que vous voulez faire passer pendant la session ? Qu’est-ce qui inquiète le sponsor en ce moment ? (Si vous ne le savez pas encore, vous feriez mieux de le découvrir dès que possible) Que faites-vous de leurs soucis ? Qu’avez-vous fait à ce sujet ? (Dire simplement “nous sommes dans le processus de …” ou “nous le regardons …” est vraiment une piètre explication) Qu’est-ce qui va bien sur le projet ? – commencez toujours la réunion avec quelques bonnes nouvelles et finissez également la réunion avec quelques bonnes nouvelles Quel est le problème en ce moment précis ? Technique, budget, personnels, politique, fournisseurs Qu’est-ce qui peut être fait ? Qu’avez-vous besoin que le sponsor fasse ? – soyez spécifique Être préparé avec les KPIS et entrez dans le détail si nécessaire Quels risques ne sont pas sous contrôle ? Pourquoi ? Comment les communications avec le client/utilisateurs finaux vont-elles ? Comment l’équipe va-t-elle ? Exténuée ? Fragmenté ? Qui ou quoi a besoin du changement de changer dans l’équipe ? Quelles étaient les attentes originales du sponsor ? Ont-elles changé ? Qui connaissez-vous ? Les attentes du client ont changé ? Sont-elles réalistes ? Est-ce que le client est prêt pour l’étape suivante du projet ?

A Faire

• Prenez l’échéancier, le budget, les comptes rendus de réunion
• Assurez-vous que vous avez des renseignements à jour de chaque leader d’équipe, membre – car, parfois, les comptes rendus sont dépassés
• Amenez la liste de livrables montrant le progrès (si non inclus dans l’échéancier)

Dix Choses à regarder lors d’une revue de planning (d’échéancier) de projet

Dave Paradi a posté l’article en anglais traduit ci-dessous sur les 10 choses à rechercher en premier lieu si l’on vous demande de revoir la qualité d’un MS Project Plan ou échéancier/planning produit à partir d’un outil semblable de planification de projet. J’avais écrit un article sur 4 choses à faire pour construire un bon Work Breakdown Structure (WBS) que l’on retrouve ici.

Quand on vous donne un échéancier à passer en revue, voici dix choses que vous devriez regarder pour en déterminer le niveau de qualité.

1. Paramétrage du Calendrier

Si vous examinez un calendrier, vérifiez la date du prochain jour férié et voyez si des tâches sont prévues à cette date. Vérifiez aussi que le calendrier de projet ait le nombre approprié d’heures de travail par jour. Si ces deux aspects du calendrier de projet ne sont pas définis correctement, le planning du projet sera incorrect et amènera des problèmes de management du projet. Assurez-vous que le calendrier de projet est paramétré pour inclure les vacances statutaires et que le nombre d’heures de travail paramétré par jour correspond bien au nombre d’heures par jour utilisées pour l’évaluation.

2. Paramétrage des Ressources

Vérifiez la liste de tâche pour voir si les tâches ont toutes un coût associé. Le coût de tâche reflétera le coût en matériels et parfois également en personnel.

Ressources Matérielles : Demandez à voir la liste des ressources et contrôlez que chaque ressource matérielle y a un coût assigné. Si un coût n’est pas assigné à chaque ressource matérielle ou s’il manque des ressources matérielles, il devrait y avoir une autre manière en place pour suivre à la trace les dépenses de projet – demandez à voir cette méthode.
Ressources de Personnel : Pour des ressources de type personnel, il est aussi important de vérifier que le groupe dont la ressource fait partie (c’est-à-dire, le département) est identifié. Si une personne ne fait pas partie d’un groupe, il ne sera pas possible de lister les tâches par département pour sécuriser les engagements de ressources des managers fonctionnels. Ajoutez ces deux aspects à chaque ressource s’ils manquent.

3. Longueur de Tâche Trop Importante

Les tâches doivent être réduites à une taille qui permette une estimation précise de durée de tâche. Par exemple, pour un projet de plus de trois mois, une durée de tâche maximum de cinq jours permet le suivi précis à faire chaque semaine. Les problèmes peuvent alors être saisis plus tôt. Contrôlez pour voir s’il y a les tâches qui ont une durée plus longue que cinq jours. L’avancement d’une tâche avec une durée plus longue sera difficile à réaliser avec précision et peut mener à un problème significatif quand le déraillement de la tâche n’est perçu qu’à la fin de l’évaluation originale. Pour des projets de moins de trois mois de long, vous devriez rechercher des durées maximales plus courtes (trois jours pour projets de 2-3 mois, 2 jours pour projets de 1-2 mois et 8 heures pour les projets de moins d’un mois). Si vous voyez les tâches qui sont plus longues, demandez qu’elles soient découpées en sous tâches de cinq jours ou moins.

4. Manque de Liens ou Liens positionnés à un Niveau Incorrect

Un des avantages des plus grands logiciels de management de projet est la capacité de lier des tâches en elles pour montrer des dépendances successeur et prédécesseur. Cela permet au planning de projet de refléter que certaines tâches peuvent commencer seulement après que d’autres tâches soient achevées. Contrôlez que les tâches ont été liées et que les liens apparaissent seulement aux tâches de niveau le plus bas, pas les tâches de niveau regroupement. Vous serez capables d’identifier une tâche de niveau regroupement parce qu’elle a des tâches secondaires au-dessous et les tâches secondaires sont d’habitude indentées dans le planning projet. Sans liens entre les tâches, vous ne pouvez pas déterminer les dépendances et il sera très difficile de voir l’effet d’un problème qui arrive tôt dans le projet sur la date finale de projet. Les liens sur les tâches de niveau supérieures ne donnent pas assez de détail aux membres de l’équipe de projet pour voir correctement le séquençage des tâches et peuvent causer des problèmes dans le  logiciel s’il y a aussi des liens aux tâches de niveau inférieur. Assurez-vous que les liens entre tâches existent seulement au niveau le plus bas.

5. Ressources Assignées aux Tâches

Vérifiez cette chaque tâche de niveau le plus bas ait une ressource assignée et que les ressources ne sont pas assignées aux tâches de niveau de regroupement. Si les ressources ne sont pas assignées aux tâches, il sera très difficile de suivre la progression parce que vous ne saurez pas à qui demander. Si les ressources sont assignées aux tâches de niveau regroupement, le logiciel de management de projet calculera un coût double – une fois pour chaque tâche et ensuite de nouveau pour le coût des ressources de la tâche de regroupement. Assurez-vous que les ressources sont assignées seulement aux tâches de plus bas niveau dans le planning de projet.

6. Contraintes de Dates Imposées Utilisées

Vérifiez pour voir si le plan a forcé des dates de début ou de fin sur des tâches. En forçant le début ou la fin, la tâche a un jeu de contrainte de date imposée. Une contrainte de date causera des problèmes significatifs quand on essaiera de calculer le chemin critique. Pour voir si de telles contraintes existent, contrôlez si toutes les tâches ont une date de début différente et celle de fin, alors que peu ont des dépendances. Les dates devraient être calculées par le logiciel en utilisant les dépendances entre tâches et les durées de tâche. L’utilisation des contraintes de date diminue énormément l’utilité de logiciel de management de projet parce que le flux vers les tâches suivantes de données réelles des tâches précédentes s’arrêtera quand il se heurtera à une contrainte de date imposée. Supprimez ces contraintes de date et remplacez-les des liens appropriés entre tâches.

7. Ressources Surchargées

Demandez un rapport du l’allocation des ressources et cherchez les ressources qui sont prévues pour travailler plus d’heures par jour que le nombre standard d’heures dans une journée ouvrable normale. En surchargeant une ressource, il y a moins de probabilité que les tâches assignées à cette ressource soient faites à l’heure et la productivité de cette personne souffrira en conséquence. Cependant, parfois une ressource apparaît surchargée parce qu’elle a été assignée à une tâche où en fait, elle supervisera seulement une tâche qui sera réalisée par d’autres ressources. Faites des changements au planning de projet pour vous assurer que les ressources travaillent un nombre raisonnable d’heures par jour.

8. Jalons Manquants ou Non Liés dans le Planning

Pour trouver un jalon dans une liste de tâche, cherchez les tâches qui ont une durée zéro. C’est la meilleure façon d’identifier un jalon. Dans un Gantt qui donne une vue graphique, vous devriez voir des jalons comme des losanges. Les tâches jalon ayant une durée plus grande que le zéro ont été incorrectement saisies. Les jalons donnent des buts intermédiaires pour une équipe projet et sans ceux-ci l’équipe d projet risque de manquer la date de fin du projet. Les jalons sont les poteaux indicateurs qui permettent de célébrer et ré-énergiser le projet. Si les jalons ne sont pas liés dans le plan de projet, l’équipe ne saura pas comment atteindre les jalons ou quelles tâches débuter une fois qu’un jalon est atteint. De plus, il sera impossible d’identifier le chemin critique. Assurez-vous que les jalons sont correctement identifiés et liés dans le planning du projet.

9. « Décalages avec retard » (lag time) absents

Contrôlez que les temps de décalage avec retard dans le projet ont été identifiés et représentés dans le planning du projet. Un retard ou une attente se produisent  d’habitude quand l’équipe a besoin d’une approbation ou attend un renseignement. Il y a deux manières de trouver les décalages avec  retard  dans le planning. Une façon est de chercher les tâches qui disent “Attendant …” et qui ont une durée mais aucune ressource assignée. L’autre manière d’identifier un retard est de regarder le champ prédécesseur. Il donnera le numéro de la tâche précédente et ensuite “+ x jours” pour montrer le temps de retard. Si ces décalages ne sont pas dans le plan, l’échéancier sera par trop optimiste et l’équipe devra s’accommoder de plus de changement de planning que  nécessaire. Les décalages avec retard permettent aussi à l’équipe de projet de faire un suivi des items qu’ils attendent et de garder le projet sur les rails. Assurez-vous que vous identifiez les décalages avec retard et leurs liens dans le planning du projet.

10.  Le suivi ne permet pas de prédire le futur

Quand un projet est déjà commencé, vérifiez pour voir si le suivi des données réelles prévoit comment le projet évoluera. Si la méthode de suivi de complétude par pourcentages est utilisée, elle suppose que toutes les évaluations de durée de tâches originales sont correctes, ce qui d’habitude n’est pas vrai. Vous pouvez dire si cette méthode est utilisée si vous voyez que toutes les dates de fin prévues sont égales aux dates de prévision initiale bien que le projet ne soit pas parfaitement dans les temps. L’équipe de projet devrait, toutes les semaines, capturer le coût/travail réel pour chaque tâche, comparer cela avec leur estimation de départ  et recalculer le reste à faire coût/travail de chaque tâche. Le planning de projet devrait inclure des colonnes pour les dates de prévision initiale de début et de fin ainsi que les dates réelles ou re-planifiées. Cela donne à l’équipe projet une meilleure prédiction de quand chaque tâche sera en réalité complète. Le logiciel de management de projet utilise alors ces dates prévues d’achèvement pour calculer l’impact sur les tâches futures, mettant à jour le début prévu et les dates de fin des tâches suivantes. Vérifiez la méthode de suivi pour vous assurer qu’elle permet de prévoir l’état futur du projet.

En vérifiant ces dix aspects, vous pouvez vous assurer que le planning de projet va plus probablement amener à un projet réussi.

Cours sur le web de Gestion de Projets – Ecole Centrale de Lille

Rémi Bachelet, Maître de conférences à Ecole Centrale de Lille, a mis en ligne des cours de gestion de projet, en micro-apprentissage (microlearning) en diapositives animées, vidéo, ppt, pdf…

http://rb.ec-lille.fr/gestion_projet.htm

a win-win approach to project managers development

As president of PMI France-Sud, I was often told by different companies: « We’re not very good at Project Management! » And my comment back to them was: « So, what are you going to do about it? ».

Indeed, some companies have poor project management capabilities. But are they just « getting what they deserve » for the lack of attention they pay to this tough profession? Developing a robust project management capability is an obligation in most companies nowadays.

Read the full story

La même chose en Français.

De nombreuses méthodes de management de projet – Many PM methodologies

Suite à une demande sur un forum LinkedIn, Marc Bonnemains, partage avec nous une liste de méthodes qui sont utilisées dans différents contextes métiers et pays à travers le monde.

Nous avons différentes méthodes de gestion de projet à ne pas confondre avec un corpus de connaissance comme le PMBOK, bien sûr.

• Prince2
• IPMA Compétence base line
• APM Body of knowledge
• GAPPS - Global Alliance for Project Performance Standards
• La conduite de projets à l’IN2P3
• HERMES - La méthode suisse de conduite de projets
• Japanese Project Management – Project and Program Management for Enterprise Innovation (P2M)
• IEEE Software Engineering Standards
• ADePT Methodology (nouvelle approche)
• Il existe aussi des méthodes de gestion de projet pour ONG – COTA
• Peace Corps – Peace Corps Programming and Training Manual
• SCALPS : Guide des projets scientifiques du CNES – Support méthodologique commun, il est destiné aux laboratoires, entreprises, industriels et aux responsables du CNES chargés du développement de produits. Il a pour objectif de leur apporter un soutien dans la conduite de projet, et de renforcer leur autonomie envers les agences spatiales.
• Référentiel QUAPITAL-HERMES V1.2 – Issue de la méthode HERMES créée par l’Unité de Stratégie Informatique de la Confédération suisse (USIC), le référentiel QUAPITAL-HERMES est une solution globale personnalisée et optimisée pour le Luxembourg.
• Méthode de gestion des risques de sécurité OCTAVE® – For an organization that wants to understand its information security needs, OCTAVE® (Operationally Critical Threat, Asset, and Vulnerability EvaluationSM) is a risk-based strategic assessment and planning technique for security.
• Différent outils méthodologiques élaborés et maintenus par l’ANSSI sur l’aide à la prise en compte de la sécurité dans les systèmes d’information. EBIOS – Expression des Besoins et Identification des Objectifs de Sécurité, PSSI – Guide d’élaboration de politiques de sécurité des systèmes d’information, TDBSSI – Guide d’élaboration de tableaux de bord de sécurité des systèmes d’information, GISSIP – Guide d’Intégration de la Sécurité des Systèmes d’Information dans les Projets, Guide relatif à la maturité SSI.
• La conduite de projet informatique vue par le CNRS. Le CNRS étant toujours une référence en France, je vous invite à découvrir la méthodologie en conduite de projet que le CNRS préconise pour le domaine des Systèmes d’Information.
• D’autres liens / other links : Papers, Links and Project Management Resources.

manager les problèmes sur le projet avant qu’ils ne deviennent des bombes

L’auteur nous rappelle la criticité et l’importance de traiter bien et rapidement les questions qui surgissent au cours du projet et qui peuvent se transformer en problèmes à résoudre pour réussir le projet.

J’ai personnellement expérimenté cet aspect du management de projet sur un projet d’intégration et de déploiement logiciel de grande ampleur. Nous avions, comme le suggère l’auteur, créé une base de données des questions et problèmes dans lequel toutes les parties prenantes pouvaient saisir question ou problème perçu. Le Project Office, que je dirigeais, se chargeait de qualifier les questions, en y répondant si possible immédiatement. Si une solution rapide ne pouvait être apportée par le Project Office, nous mettions la question/problème à l’ordre du jour de notre revue journalière et demandions à la personne ayant soumis la question de venir en discuter brièvement. Cette revue d’une durée de 30′ à 13h30 chaque jour, était suivie par les chefs des sous-projets du programme. Nous décidions ensemble de qui allait adresser le sujet et avec quelle urgence (low/medium/high/critical). L’objectif étant systématiquement d’empêcher un vrai et gros problème de se développer. Nous suivions ensuite à ce niveau les questions jugées critiques et produisions des statistiques sur le nombre de problèmes ouverts, nouveaux, fermés et la durée moyenne de réponse par niveau de criticité. Sans cette approche rigoureuse, nous aurions certainement vu déraper le projet, enseveli sous une masse de questions et problèmes non résolus.

Donc, répondons aux questions et gérons les problèmes dès que possible pour éviter qu’ils ne s’enveniment.

Manager les « Problèmes » projet

Http://www.pmhut.com/managing-project-issues

Par JISC infoNet

Il est difficile de trouver une bonne définition formelle d’un « Problème ». Un Problème est essentiellement quoi que ce soit qui pourrait empêcher le projet d’atteindre ses objectifs. Il est peut-être le plus facile d’expliquer la différence entre des problèmes et des risques. Un risque est une occurrence potentielle tandis qu’un problème est quelque chose qui est déjà arrivé. La bonne gestion des risques empêchera bien sûr beaucoup de risques de se métamorphoser en problèmes réels.

Une zone d’ombre est la différence entre un problème et une question. Par exemple une partie prenante de votre projet peut demander:

Comment impliquez-vous les conférenciers dans l’exécution du nouveau VLE (l’Environnement d’apprentissage Virtuel – « Virtual Learning Environment ») ?

Mais ce qu’ils disent en réalité est :

Je ne pense pas que les conférenciers sont engagés de manière adéquate dans la mise en œuvre du VLE.

Pour cette raison, cela vaut souvent la peine d’enregistrer les questions et de s’assurer qu’on leur réponde pour les empêcher de se métamorphoser en problèmes. Une question a d’habitude une réponse factuelle directe. Par exemple: “Il y a un groupe de travail pour les conférenciers qui veulent s’impliquer dans le projet.”

Un problème est quelque chose qui ne peut pas facilement être résolu avec une réponse factuelle. Par exemple: un membre du personnel nous quitte inopinément ou un fournisseur clef passe en administration judiciaire.

Les problèmes peuvent présenter des opportunités aussi bien que des menaces. Un problème pourrait être du type « je ne pense pas que vous le fassiez très bien, voici une meilleure suggestion …”. Dans ce cas un problème pourrait aboutir à une proposition de changement au projet. Cela peut affecter la portée de votre projet mais le changement peut être pour le meilleur.

Vous pouvez avoir anticipé quelques problèmes dans votre évaluation de risque initiale alors que d’autres vont surgir inopinément. Les mécanismes pour enregistrer et traiter les problèmes imprévus incluent :

• Tenir un Journal des Problèmes
• S’assurer que le progrès, le comité et d’autres réunions de Projet allouent du temps à la discussion de problèmes
• Se mettre d’accord sur des groupes de travail focalisés et de durée limitée si un grand nombre de parties prenantes est affecté

Le concept d’avoir un propriétaire pour chaque problème est crucial à un management efficace des problèmes. Le propriétaire est quelqu’un dans l’équipe de projet qui est responsable de s’assurer que le problème soit résolu. Tous les membres de l’équipe devraient être encouragés à signifier les problèmes aussitôt qu’ils surgissent (souvent cela arrive d’abord au cours de discussions informelles) et un propriétaire approprié devrait être déterminé. Généralement la responsabilité devrait être au niveau le plus bas auquel le problème pourrait probablement être résolu. Cela peut être décidé par le Chef de projet assignant le problème à quelqu’un comme un livrable de travail avec ses propres temps et coûts admis.

Plus un problème est enregistré et attaqué tôt et plus il aura de chances d’être résolu sans avoir un impact majeur sur le projet. Vous devriez cependant déterminer une procédure d’escalade au cas où une solution ne puisse pas être mise en œuvre dans les délais et coûts admis par le propriétaire initial.

Normalement le problème sera remonté par la structure de management du projet jusqu’au Chef de projet et, en fin de compte, le comité de projet pour une décision s’il ne peut pas être résolu dans la tolérance admise dans cette étape.

En « cascade » + RUP + Agile : Complémentarité plutôt qu’opposition

J’ai apprécié cet article où l’auteur a pris le parti de la complémentarité plutôt que de l’opposition entre les méthodes de développement traditionnelles et plus récentes.

Le choix entre les méthodes « en cascade », RUP et agile, y 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 dimension géographique.

Ce qui représente en soi, un bon exemple d’agilité dans le choix même de l’approche qui pourrait être une combinaison des trois méthodes selon les moments du cycle de développement.

Utilisez vous d’autres critères de choix de l’approche de développement?

En « cascade », RUP et Agile : quelle est la bonne méthode de développement logiciel  pour vous?

Article original de Serhiy Kharytonov, SoftServe © 2009

Http://www.executivebrief.com/software-development/waterfall-rup-agile/

Rationalisez la production avec les processus rapides et efficaces « en cascade », RUP et Agiles. Créez le bon mélange des stratégies de développement de logiciels afin de répondre aux besoins spécifiques de votre projet.

Malgré les signes de reprise dans l’économie, la réalité persiste dans le développement logiciel. La plupart des sociétés et clients ont besoin de leur logiciel pour hier avec les fonctionnalités les plus avancées au coût le plus faible possible. Pour atteindre ces buts apparemment contradictoires, les développeurs cherchent à rationaliser la production avec les processus rapides, efficaces qui peuvent donner au client ce qu’il/elle veut en un laps de temps le plus court possible.

Ces faits 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 du passé, souvent appelé le modèle « en cascade », aux modèles plus itératifs et progressifs tels que « Rational Unified Process (RUP) » et « Agile. »

Les partisans d’Agile sont nombreux et il peut parfois sembler que des processus de développement plus traditionnels sont tombés en défaveur, mais en réalité les trois modèles ont leurs avantages, des côtés négatifs et leurs environnements de projet favoris. Au bout du compte, la meilleure méthode ou le meilleur mélange de méthodes pour vous dépend d’une compréhension minutieuse des trois processus et comment ils s’adaptent à votre projet logiciel, la culture business et l’environnement de développement.

En « cascade »

La programmation en « cascade » est un processus fortement structuré qui compte lourdement sur la planification initiale et un ensemble d’étapes séquentielles, prescrites qui coulent de l’une dans l’autre comme une chute d’eau. Chaque étape a typiquement son équipe propre d’experts et des jalons soigneusement préparés d’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.

Typiquement les étapes dans le développement en « cascade » sont :

1. Recueil des besoins et rédaction du cahier des charges
2. Analyse fonctionnelle
3. Développement du code
4. Intégration
5. Test et mise au point
6. Installation
7. Maintenance

Le développement en « cascade » 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 la « cascade » demande simplement trop longtemps et manque de la flexibilité – ou de l’agilité – requise pour le marché logiciel d’aujourd’hui et un 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 au moment où 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 être des corrections onéreuses, explosant le budget.

RUP

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 d’accommoder le changement et l’adaptabilité pendant le processus de développement.

Comme la « cascade », RUP a une série de phases et des jalons qui coulent l’un dans l’autre. Les phases consistent en :

1. Création (« inception »), où la portée du projet, l’évaluation des dépenses, des risques, le business case, l’environnement et l’architecture sont identifiés.
2. L’élaboration, où les besoins sont spécifiés en détail, l’architecture est validée, l’environnement de projet est détaillé et l’équipe de projet est configurée.
3. La construction, où le logiciel est construit et testé et la documentation de support est produite.
4. La transition, où le logiciel est testé au niveau système et utilisateur, corrigé et déployé.

RUP définit aussi les rôles et les activités de membres de l’équipe en détail 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 les grandes quantités de documentations requises pour chaque étape de la « cascade ». Tous les membres de l’équipe ont accès à la même grande base de connaissance de directives, modèles, outils et autres articles pour assurer qu’ils partagent les mêmes langage et perspective sur le projet.

Alors que cela apparaît semblable au développement en « cascade » de prime abord, la plus grande différence du RUP est son approche de développement itérative, qui construit le produit dans 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 et d’architecture et l’exploration d’idées différentes, tandis que les itérations ultérieures essayent de rassembler 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.

Non seulement le processus RUP est itératif dans son ensemble mais RUP suppose aussi que chaque phase ait plusieurs itérations internes basées sur des retours d’utilisateur.

RUP adresse bon nombre des critiques du développement en « cascade » et 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 » 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 et 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 ou bien pour le Web 2.0 et les environnements Software-as-a-Service (SaaS) où on s’attend à des mises à jour fréquentes et des compléments de fonctionnalités.

Agile

Tandis que la « cascade » et RUP penchent vers la prévisibilité, 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, y compris XP et SCRUM, mais tous s’efforcent de mettre une version de 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 des 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 sessions de deux à quatre semaines. Bien que le processus Agile soit planifié d’avance comme la « cascade » et RUP, il fait passer les gens et la collaboration avant le processus lui-même.

Plutôt que de dépendre de nombreuses équipes d’experts, le processus de développement Agile entier 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 collaboration en face à face constante est le but, avec le représentant du client utilisé comme l’un des collaborateurs les plus importants. La documentation est dé-priorisée par rapport à la « cascade » 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 de besoins et des défis compétitifs, qui sont les raisons de tant de partisans. British Telecom est fréquemment cité comme une société qui a utilisé la programmation Agile avec beaucoup de succès, avec des cycles de développement de 30 à 90 jours qui ont rapporté 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, elle a aussi ses limitations et inconvénients. Son accent sur les réunions quotidiennes en physique et la collaboration rapprochée rendent le processus difficile à adapter à l’externalisation des développements, aux clients et développeurs géographiquement distribués, ou aux clients qui n’ont tout simplement pas la main d’œuvre, les ressources ou l’attention nécessaires.

Son accent sur la modularité, le développement progressif et l’adaptabilité ne convient pas facilement aux clients qui veulent des contrats avec des évaluations fermes et des calendriers fixes. Sa dépendance sur de petites équipes auto-organisées rend difficile l’adaptation aux grands projets logiciels avec beaucoup de parties prenantes aux besoins  différents et néglige de prendre en compte du 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 la « cascade » 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.

Le meilleur de chaque monde

Si Agile, RUP et des modèles en « cascade » ont chacun leurs inconvénients, lequel devriez-vous choisir ? De plus en plus, le secret au développement logiciel réussi est de comprendre les trois processus dans le détail et sélectionner les parties de chacun qui conviennent le mieux à votre livrable et environnement particuliers. Puis, être agile dans l’approche même du processus, en regardant sans cesse sur 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 à vos circonstances actuelles.

Par exemple, si vous développez du logiciel SaaS ou Web 2.0 dans un marché fortement concurrentiel, alors vous ferez probablement le meilleur choix en penchant vers des méthodologies Agiles. SaaS se prête particulièrement bien à Agile puisqu’il prévoit un accès constant au logiciel pour ajouter ou changer des caractéristiques. Dans un tel marché concurrentiel avec des besoins utilisateur 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 d’autres systèmes qui exigent un haut degré de conception et de certitude, alors il semble logique de commencer par la « cascade ».

Si vous produisez un progiciel grand public « sur étagère », avec de nouvelles versions qui doivent être des enrichissements des versions précédentes, votre processus devrait probablement pencher vers RUP, avec une attention particulière au recueil des besoins, à la définition du périmètre et du contenu au début, ainsi que des standards de navigation, et d’interface utilisateur.

Cependant, les développeurs peuvent tout de même utiliser des techniques Agiles pour présenter des prototypes fréquents et des modules progressifs 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 société – selon que ces équipes soient plus ou moins habituées à une telle collaboration. Quand la géographie 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’entreprise externalisant le 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 contact de suivi qu’il est possible pour votre projet, la culture de votre société et celle de vos partenaires de développement.

Choisir de partir sur des équipes auto-organisées ou une approche plus « top-down »  de management dépend vraiment du niveau de compétence et d’expérience de vos développeurs. Beaucoup de projets peuvent exiger au départ un leader 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 pour les itérations suivantes.

Le bilan est qu’il n’y a probablement aucun processus parfait pour tous les projets et 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. Bref, en choisissant entre Agile, RUP et en « cascade », adaptez le processus à vos besoins, plutôt que d’adapter votre projet au processus.

why quick fixes often lead to more trouble

As project managers, we’re often compelled to get roadblocks out of the way as fast as possible so the team can continue to progress. Therefore, we’re quite often in problem solving mode, trying to resolve issues that arise, avoiding and mitigating risks. A useful thing to keep in mind is to always consider whether we are really addressing the issue or only a symptom of the issue. Is our quick fix action aimed at the root cause of the issue or is it a step in the right direction as we fix the symptom? If yes, that’s ok and we shall apply the quick fix. But it’s not always the case…

This post is inspired by a training session I organized and attended for the management board of the PMI France-Sud non-profit organization a couple of years ago. Jerry Brightman, a renowned leadership expert and President of a company called The Leadership Group, was kind enough to facilitate this session.

Let’s take an example to illustrate the topic: a team member comes into your office to announce a probable delay on one of his deliverables. I propose that we walk through this case to better understand what could be happening.

The way it usually starts:

1. We see a problem, or to be more precise the symptom of a problem. I.e. by definition of a symptom: « a sign, indication, manifestation; something caused by and indicative of a certain disease or disorder. » In this example, a team member signals that he may not be delivering his part of the project on time.

2.We apply a quick fix. This deliverable is on our critical path, we propose to provide some additional assistance to the person to get the task completed on time.

Let’s assume that indeed this fixes the symptom. In our example, the task is back on track.

However, are we sure to have

a) addressed the root cause of the problem and

b) assessed the potential side effects of the quick fix we applied?

Let’s see what too often takes place after the initial quick fix.

3. The quick fix addresses the symptom but it has some side effects. For example, the additional help provided provokes a delay on another task from which we pulled some resources, or it generates requests from many others to get more resources, or it demotivates team members who were going the extra-mile to be on time, or…

4. These side effects will manifest through new symptoms: Bad morale in the team, threats of delays in other parts of the project, absenteeism…

5. We’re tempted to address these new symptoms with more quick fixes.

The loop goes on. The initial quick fix may have placed the entire project at risk.

So, what to do? How do we break the vicious spiral?

The proposal is to try by all means to avoid entering into this spiral.

In step 1, when we see the symptom (the threat of a late deliverable that is on the critical path), we take a step back to understand why the symptom is there and what caused it. We will want to ask a few questions such as:

• Were the estimates incorrect?
• Did a risk materialize that we had or not accounted for?
• Were there changes to the requirements and how were these managed?
• Were some resources not available when they should have been?
• Was the learning curve incorrectly appreciated?
• Did we encounter technical issues?

We see that the answers to the above questions may drive us in step 2 to a completely different quick fix that should be better suited to address the primary/root cause and avoid or anticipate some of the side effects.

As Seth Godkin highlighted it in of his posts: Bear shaving will not resolve global warning.

Or what my first aid teacher repeated to his students: « Do not put a Band-Aid on a non disinfected wound. »

Pourquoi les réparations rapides amènent-elles souvent plus de problèmes qu’elles n’en résolvent ?

L’un des rôles du chef de projet est d’éliminer le plus rapidement possible tout obstacle qui empêcherait l’équipe de progresser. Nous sommes donc souvent en mode « résolution de problème », essayant de répondre aux questions qui surgissent, d’éviter et/ou atténuer les risques. Il est utile de nous poser la question de savoir si ce que nous essayons de résoudre est réellement le problème ou seulement un symptôme du problème. Notre réponse ou réparation rapide s’attaque-t-elle à la cause première/racine du problème ? Est-ce une étape dans la bonne direction pour réparer le problème de fond ? Si oui, ok pour cette réparation rapide (« quick fix »). Mais cela n’est pas toujours le cas …

Cet article est inspiré d’une session de formation que j’avais organisée et suivie pour le bureau de l’association PMI France-Sud. Jerry Brightman, un expert renommé du leadership et Président de la société The Leadership Group, fut l’animateur de cette session.

Prenons un exemple pour illustrer le sujet : un membre de l’équipe entre dans votre bureau pour annoncer un possible retard sur l’un de ses futurs livrables. Je propose que nous suivions ce cas pas à pas pour mieux comprendre ce qui pourrait arriver.

Voici comment cela commence habituellement :

1. Nous voyons un problème, ou pour être plus exacts le symptôme d’un problème. C’est-à-dire selon la définition du mot symptôme : « un signe, une indication, une manifestation; quelque chose de causé par et indicatif d’une certaine maladie ou désordre. » Dans notre exemple, le symptôme est le signal de l’un des membres de l’équipe qu’il ne livrera probablement pas sa partie dans les temps.

2. Nous appliquons alors une réparation rapide. Ce livrable est sur notre chemin critique, nous proposons de fournir un peu d’aide supplémentaire à la personne pour l’achever dans les délais prévus.

Supposons que cela fonctionne et répare en effet le symptôme. Dans notre exemple, la tâche à réaliser est de nouveau dans les temps.

Cependant, sommes-nous sûr d’avoir

a) Attaqué la cause première/racine du problème et

b) Évalué les effets secondaires potentiels de la réparation rapide ?

Voyons ce qui arrive trop souvent après une réparation rapide.

3. La réparation rapide adresse le symptôme mais elle a quelques effets secondaires. Par exemple, l’aide supplémentaire sur une tâche provoque un retard sur une autre tâche dont nous avons utilisé des ressources, ou elle produit des requêtes d’autres membres pour obtenir davantage de ressources, ou elle démotive les membres de l’équipe qui fournissaient des efforts supplémentaires importants pour rester dans les temps sur leurs propres parties du projet, ou …

4. Ces effets secondaires se manifesteront par de nouveaux symptômes : mauvais moral dans l’équipe, menaces de retards sur d’autres parties du projet, absentéisme …

5. Nous serons tentés d’adresser ces nouveaux symptômes par davantage de réparations rapides.

La boucle continue. Cette réparation rapide initiale peut avoir placé tout le projet à risque.

Aussi, que faire ? Comment casser ce cercle vicieux ?

La proposition est de s’efforcer par tous les moyens d’éviter d’entrer dans cette spirale.

Dans l’étape 1, quand nous observons le symptôme (la menace du retard d’un livrable qui se trouve sur le chemin critique), nous prenons un peu de recul pour comprendre pourquoi le symptôme est là et quelle en est la cause. Nous nous posons ainsi qu’à l’équipe certaines questions telles que:

• Est-ce que les évaluations de charge étaient incorrectes ?
• Un risque s’est-il matérialisé que nous n’avions pas prévu ou incorrectement managé ?
• Un changement des besoins est-il intervenu et comment a-t-il été géré ?
• Est-ce que des ressources n’étaient pas disponibles quand elles auraient dues l’être ?
• La courbe d’apprentissage a-t-elle été mal appréciée ?
• Avons-nous rencontré des difficultés techniques ?

Nous voyons que les réponses aux susdites questions peuvent nous amener dans un 2^ème étape à une réparation rapide peut-être totalement différente et qui devrait être plus adaptée pour adresser la cause première/racine et éviter ou anticiper certains des effets secondaires.

Comme Seth Godkin l’avait mis en évidence dans un article : Raser les ours polaires ne résoudra pas le réchauffement climatique.

Ou encore, comme mon enseignant en premiers secours le répétait à ses étudiants : « Ne mettez pas de pansement sur une blessure qui n’est pas désinfectée. »

Un bon compromis vaut-il mieux qu’un consensus « mou »?

Article original: http://www.pmhut.com/consensus-and-compromise-in-project-management

« Consensus et compromis dans le management de projet » de Susan Dodia

L’article traduit ci-dessous a attisé ma curiosité. En fait, parce qu’il fait l’éloge du consensus alors que je pense qu’un bon compromis peut-être bien meilleur que certains consensus. A la relecture, j’ai réalisé que le type de consensus qui est décrit, à la fois fort, compris et supporté par tous de manière active, est effectivement préférable aux compromissions.

Mon expérience cependant est que très peu de consensus combinent ces caractéristiques. La plupart me semblent être des consensus que je qualifierais de « mous ». En fait, personne de daigne objecter à la solution ou au projet proposé. Mais cela ne signifie pas grand chose car tous n’apporteront pas véritablement leur support. Très peu se sentiront personnellement engagés par la décision. Beaucoup n’auront pas osé exposer leur désaccord face à l’audience alors que leurs raisons auraient méritées un débat contradictoire.

Le pire est lorsque de telles réunions pour arriver à un consensus sont réalisées par conférence téléphonique sans pouvoir apprécier visuellement les signes d’acceptation ou les freins de chacun. Ces réticences seront souvent tues face au pouvoir de la majorité ou des plus vocaux. Dans ce cas, un compromis qui mettrait en évidence ce que chacun attend et ce qui est concédé ne peut-il être plus efficace?

Alors qu’en pensez-vous? Quelles sont vos expériences personnelles? Parviendrons-nous à un consensus fort parmi les lecteurs de ce blog ou bien à un compromis? L’utilisation de la video conférence permet-elle d’atteindre plus facilement des consensus forts?

Début de la traduction:

Comprenez-vous la différence entre consensus et compromis ? Les mots se ressemblent mais la distinction est importante.

La définition de dictionnaire de consensus est “Accord et consentement du plus grand nombre; harmonie”, tandis que le dictionnaire définit le compromis comme “Action qui implique des concessions réciproques ; transaction”.

Nous sommes tout familiers avec le compromis dans des décisions faites par nos équipes de projet. Nous renonçons tous à un peu de ce que nous voulons pour faire de la place à un peu de ce que les autres veulent. Les bons jours, chacun est seulement légèrement insatisfait.

Le consensus, d’autre part, est une décision de groupe supportée par tous les membres basée sur :

• Une compréhension minutieuse de toutes les informations appropriées
• Participation de tous les membres
• Une compréhension des différentes perspectives et besoins
• Des efforts créatifs pour répondre à des besoins différents
• Un empressement à soulever, comprendre et résoudre les désaccords

Judy Mares-Dixon définit le consensus comme “le meilleur effort d’un groupe afin de réaliser son résultat le plus brillant. Le consensus est l’accord de niveau le plus haut avec lequel nous pouvons tous vivre. Le compromis demande d’abandonner des choses. Le consensus est de l’obtention du meilleur des idées de chacun. Le consensus est la réunion de toutes les idées différentes pour inventer quelque chose de mieux que ce que nous aurions identifié de notre propre chef.”

Alors, comment déplacer votre équipe du compromis au consensus ?

Voici quelques options :

• Revoyez les intérêts de chacun et concentrez-vous sur ce qui peut être fait, pas ce qui ne peut pas être fait
• Prenez une pause, plaisantez, faites bouger les personnes
• Si un coté menace avec un certain type d’ultimatum, discutez de ce à quoi il ressemblerait. Quelles sont les conséquences ? Voyez si vous pouvez être d’accord, comme une équipe, que ces conséquences devraient être évitées.
• Estimez le niveau d’inassouvissement dans un groupe : demandez aux gens de classer la solution proposée sur une l’échelle de 1-3 ou 1-4. C’est utilisé vers la fin pour se faire une idée de si une option vaut la peine d’être poursuivie et combien de temps cela prendra pour atteindre le consensus. Demandez à ceux qui classent les solutions le plus bas de proposer leurs solutions potentielles.
• Si vous vous trouvez avec un dissident au cours des discussions, demandez-lui comment il veut traiter le fait qu’il est la voix discordante. Un défi avec le consensus consiste en ce que nous donnons au dissident beaucoup de pouvoir, donc c’est une bonne stratégie quand le groupe commence à se retourner contre le dissident.
• Une stratégie finale est de donner la décision à un tiers. Vous ne parvenez pas à  choisir un nom pour votre projet ? Donnez-le au Marketing. Vous ne parvenez pas à vous mettre d’accord sur l’échéancier? Demandez à une responsable d’équipe d’un autre projet de regarder vos informations et de décider. Cela peut servir de tie-break, ou ramener votre équipe à la table pour le retravailler eux-mêmes.