Une petite vidéo en Français, à la fois pertinente et amusante, sur l’utilisation par les chefs de projets d’outils tels que le tableur Excel pour gérer leurs projets par rapport à MS Project.
Catégorie : outils et méthodes
MS Project 2010 de A à Z
Voici une présentation pour entrer dans les détails de la nouvelle version du logiciel phare MS Project 2010. Cette vidéo a été enregistrée au TechDays de Microsoft et passe au travers des principales nouveautés de MS Project 2010. Elle est délivrée par Vincent Capitaine, consultant en management de projet chez TeamSquare.
Les nouvelles fonctionnalités, et en particulier le ruban qui regroupe les fonctions logicielles de manière plus intuitive pour l’utilisateur, sont commentées par ailleurs sur plusieurs blogs. On y trouve aussi une description de la fonctionnalité de planification manuelle qui permet de faciliter les saisies du planning même avec des informations incomplètes. La ligne chronologique de temps paramétrable pour communiquer et partager l’information plus facilement avec toutes les parties prenantes.
Frédéric Bojman, chef de produit MS Project chez Microsoft, nous conseille également de visionner cette autre vidéo en Anglais sur MS Project 2010
l’évolution des outils de management de projet
Un interview en vidéo sur l’évolution des outils de management de projet de Yves Cavarec, secrétaire général du chapitre PMI Ile de France, réalisé par Frédéric Bojman, chef de produit Microsoft Project. Yves Cavarec nous rappelle l’évolution des outils de management de projets au cours des 20 dernières années. Avantages et développement des outils, besoins et attentes des chefs de projet…
Yves met en exergue un très net besoin d’outils pour collecter l’information, l’organiser, la synthétiser, puis la communiquer plus facilement à la fois pour le manager de projet, ses équipes et toutes les parties prenantes.
SCRUM ne serait pas l’apanage des seuls projets de développement de logiciels
Un point de vue original de Craig Brown sur SCRUM en tant que méthode universelle et non pas seulement réservée aux projets de développement de logiciels.
Voici ce que je retiendrais de la description qu’il en donne et qui s’applique à tout projet:
- Commencez avec un objectif. Puis, décomposez-le en étapes incrémentales.
- Discutez les étapes avec l’équipe qui doit livrer la solution.
- Définissez des périodes de temps standards (timeboxing) pour les itérations. Faites de votre mieux pour livrer quelque chose de pratique et d’utile à chaque itération.
- L’équipe doit prendre ses « ordres » du client au début de chaque itération et faire un rapport sur ce qui a été « fait » à la fin de chaque itération.
- L’équipe doit mettre du temps de coté au début de chaque itération pour planifier son travail.
- L’équipe doit mettre du temps de coté pour une brève session journalière d’échanges entre membres sur les progrès et les problèmes.
- L’équipe doit s’engager à l’amélioration continue et mettre du temps de coté à chaque itération pour réfléchir sur ce qui est allé bien ou pas et où l’on peut s’améliorer.
- La planification, la revue et les sessions de réflexion et réunions d’équipe quotidiennes doivent avoir lieu à des heures régulières pour aider l’équipe à acquérir un tempo.
ma rencontre avec XTrem7, une approche Ressource Humaine innovante
Grâce à PMI France-Sud j’ai rencontré deux consultants de la société RB Conseil qui utilisent cette approche et qui sont venus la présenter à une cinquantaine de professionnels du management de projet réunis pour l’occasion. Donc, une fois de plus, merci PMI.
Avant d’assister à la session, les consultants nous avaient proposé de remplir un questionnaire en ligne afin de mettre en pratique et de mieux comprendre les concepts et outils sur un cas concret: soi-même.
En introduction, on nous rappela quelques principes de base tels que: « La réalité est subjective » et donc ma vérité n’est pas forcément celle des autres; et « Il faut toujours distinguer la personne de son comportement » car une personne est bien plus que ce qu’elle laisse transparaître au travers de ses comportements.
L’approche distingue 7 ressources, toutes utiles à l’individu selon les circonstances et qui se répartissent sur 4 quadrants d’un cercle selon qu’elles combinent rationnel ou irrationnel avec associé (reptilien, limbique) ou dissocié (Cortex).
Ces 7 ressources ne sont pas des compétences mais plutôt des priorités dans la façon d’agir et de réagir. Nous utilisons toujours plusieurs de ces ressources simultanément ou presque. Mais l’intérêt principal de cette méthode selon moi est qu’elle reconnaît explicitement qu’une personne n’est pas la même quelque soit le contexte. En effet, une même personne saura mobiliser des ressources différentes pour une réunion amicale ou une difficile session de recadrage d’un collaborateur. Il y a pour chacun la nécessité de s’adapter aux circonstances.
Dans XTrem7, cette adaptation est appelée la dynamique et se compose de 7 étapes. Voir cette animation sur le site RB Conseil. Le premier état est celui dans lequel nous sommes au naturel, quand tout va bien, que nous ne subissons aucun stress. Nous nous y sentons très confortables. Mais une situation de stress nous fera sortir de cet état pour nous emmener vers d’autres étapes où d’autres ressources devront être mobilisées pour répondre au stress. L’étape 2 par exemple est appelée « implication naissante ». Bien que nous ne ressentions pas encore de stress, c’est celle des petits soucis, du travail très accaparant ». Puis vient « l’implication réelle », situation difficile dont nous nous efforcerons de sortir rapidement car elle est inconfortable. Si les circonstances continuent de se dégrader, nous atteindrons une zone de stress majeur où nous devrons déclencher des ressources d’urgence afin de ne pas rester trop longtemps dans cette zone risquée: dépression, colères, actions irréfléchies…
La finesse de cette approche que je vous invite à découvrir dans plus de détails, est de savoir identifier à travers un questionnaire quelles ressources sont celles que vous mobilisez personnellement selon votre niveau de stress. Cet éclairage très intéressant vous permettra de mieux comprendre vos réactions ainsi que celles des autres (membres de l’équipe, sponsors, clients…). Fort de cette information, vous pourrez vous efforcer de maintenir tout ce petit monde en zones 1 et 2, plus détendues et productives. Outil donc à utiliser pour soi-même comme en équipe pour améliorer l’ambiance et l’efficacité.
Confessions of an Agile Project Manager
Des présentations au format Pecha Kucha (20 slides de 20 secondes, soit un peu plus de 6′ par video) à découvrir tant pour le contenu que pour le format.
We have many excellent confessions, now we need your help to pick the best
The community has spoken and we are impressed. With our official call for videos now concluded, we have eight distinct « Confessions » of project managers sharing their experience using Agile practices.
The PMI Agile Community of Practice (CoP) invites you to share these experiences and help us by voting for those you think are best. We will be accepting votes via Youtube comments through June 14th.
You can view and rate the videos by going to the PMI Agile YouTube Group or the PMI Agile PBWiki page: http://agile-pm.pbworks.com/Confessions-of-an-Agile-Project-Manager.
Participation: Anyone is eligible to vote on videos
dedicate 9 minutes to the Theory of Constraints
I introduced this method of Critical Chain or Theory of Constraints in a prior article. This is not to be confused with Critical Path, another very useful concept. I found a web site with many videos that provide simple overviews of Theory of Constraints when applied to different domains.
Here is the one that can serve as an introduction:
I have not yet personally used this technique that I discovered quite recently. So, I do not have any experience to share with you in this area. But some of you may have. Would you mind sharing these with DantotsuPM’s readers?
La théorie des contraintes en 9 minutes
Je vous ai déjà parlé sur un article précédent de la Théorie des Contraintes et de la chaine critique, à ne pas confondre avec le chemin critique qui est un autre concept fort utile.
Voici une vidéo qui peut tenir lieu d’introduction:
Je n’ai personnellement rencontré cette technique que relativement récemment et je n’ai donc pas encore de retour d’expérience personnel à partager avec vous. Certains d’entre ont certainement déjà appliqué cette approche que je trouve fort pertinente pour mieux optimiser l’utilisation de ressources critiques sur un ou de multiples projets en parallèle.
Que pouvez-vous nous en dire ?
L’Art de l’estimation
Article original sur le blog expiriance.
Reconnaissons-le, fournir des estimations n’est pas une tâche facile. Faire des suppositions est beaucoup plus facile.
L’estimation n’est pas seulement l’action concrète de calculer combien de temps une tâche va prendre. Il y a beaucoup d’éléments intangibles qui ne sont pas toujours pris en considération et ce sont eux qui feront ou déferont votre projet.
Comme les organisations pensent qu’une pression toujours croissante produit des résultats plus rapidement, le besoin de précision des estimations est monté en importance au point que la plupart ont développé des standards d’estimation basés sur des produits prédéfinis. Par exemple, une société de construction a une estimation déjà prédéterminée de combien cela prend de construire une pièce de 4 mètres par 5. Un fabricant de meubles de bureau sait ce que cela demande de construire une chaise « Direction modèle Luxe », etc, etc. Ces sociétés font cela tout le temps en utilisant les mêmes outils et matériels, tous très tangibles.
PERT est un des modèles les plus simples et les plus largement utilisés pour évaluer l’effort en déterminant la meilleure estimation du temps requis (Te: Temps estimé) pour compléter une tâche, en assumant que tout se passe normalement. L’implication étant que le temps prévu est le temps moyen que la tâche exigerait si elle était répétée un certain nombre de fois au cours d’une longue période de temps (comme pour la société de construction et le fabricant de meubles de bureau ci-dessus) :
• le temps Optimiste (O) – le temps minimal requis accomplir une tâche, assumant tout se passe mieux que l’on s’y attende normalement
• le temps Pessimiste (P) – le temps maximal requis accomplir une tâche, assumant que tout tourne mal, mais excluant des catastrophes majeures
• le temps le Plus probable (M) – la meilleure estimation du temps requis accomplir une tâche, assumant que tout se passe normalement
La formule pour calculer PERT est :
Te = (O + 4M + P) / 6
J’utilise PERT tout le temps, c’est très précis et cela a prouvé sa valeur dans beaucoup de situations.
Une société de développement de logiciel sur mesure, avec beaucoup d’éléments intangibles en fonction des pré-requis du client, a mis en œuvre une méthode d’évaluation basée sur huit catégories pour qualifier la complexité d’un projet de forte, moyenne ou faible. Un certain nombre de points sont additionnés selon les réponses dans chaque catégorie : 1 point pour faible, 2 points pour moyen et 3 points pour fort. Le score total du projet détermine son facteur de complexité. Celui-ci est alors utilisé pour fournir l’estimation initiale. Si le score total est entre 8 et 12 points alors c’est un projet de faible complexité, s’il est entre 13 et 18 c’est un projet de complexité moyenne et s’il est entre 19 et 24 c’est un projet de forte complexité. Notez que toutes les organisations de développement de logiciel ne peuvent pas suivre ce modèle même s’il peut être utilisé comme une base de départ. Par exemple :
Comme vous pouvez le constater, l’estimation est un art.
Qu’en pensez-vous?
Rencontre entre Six Sigma et des projets de changements de processus
J’ai très récemment suivi un cours Six Sigma (pour devenir seulement ceinture jaune en interne dans ma société !)
Aussi, cet article m’a-t-il paru fort bien articulé pour attirer l’attention des chefs de projet sur la réalité et l’efficacité de certaines techniques d’évaluation de la qualité des processus que propose la méthode Six Sigma.
Voici donc une traduction personnelle de l’article de Harry Rever.
Chronique de Ceinture Noire : Il est plutôt risqué de mettre en œuvre des changements sans avoir d’abord vérifié ou validé que ces changements fonctionnent Par Harry Rever – Directeur Six Sigma
Maria, chef de projet, se heurte à de la résistance en essayant de faire mettre en œuvre les recommandations de son projet. Une Ceinture Noire Six Sigma, essaie d’offrir ses conseils.
Maria : Merci de me rencontrer à propos de mon projet M. Briscoe. En tant que Vice-président des Opérations, j’ai pensé que vous pourriez m’aider à traiter plus efficacement avec vos Directeurs. Ils n’ont pas été très positifs envers mes efforts.
M. Briscoe : Je pense que je connais la raison de cette réunion Maria. Mes Directeurs ne sont pas enclins à mettre en œuvre les recommandations de votre projet, n’est-ce pas ?
Maria : Eh bien oui. Vos Directeurs refusent de m’écouter. Ils ne font pas les changements que mon équipe de projet recommande. Notre équipe a travaillé dur sur ce projet. J’ai personnellement travaillé des nuits et des week-ends sur ce projet durant les six derniers mois.
M. Briscoe : Je vois, je vois. Comme vous le savez Maria, votre recommandation aboutira pour mon organisation à faire plus avec moins; j’y perdrai des ressources. Je ne peux pas me permettre de perdre davantage d’employés. Donc, Maria, je suis désolée, mais je suis d’accord avec mon équipe et je la supporte. Nous ne mettrons pas en œuvre les suggestions de votre projet.
Maria : Mais, en mettant en œuvre les recommandations de mon projet, la productivité de votre organisation s’améliorera de manière significative. Ce n’est pas juste. J’ai fini mon projet dans les temps et dans le budget.
M. Briscoe : Je vais demander à Will, Ceinture Noire Six Sigma dans mon équipe, de parler avec vous de votre projet et vous expliquer pourquoi je ne supporte pas les changements que votre projet suggère. Bonne journée, Maria.
…
Will : Salut Maria. Je crois que je peux vous aider à comprendre le point de vue de M. Briscoe.
Maria : Je ne peux pas croire que votre patron n’écoute ni moi ni mon équipe. Nous avons travaillé dur. Nous avons la charte de projet, la structure de répartition de travail, l’analyse de risques, les plans d’action, les minutes des réunions, le registre des problèmes et celui des changements, le suivi de planning et du budget, les listes de brainstorming, les matrices de priorité, les diagrammes RAM, les rapports de présence et l’analyse coûts/bénéfices. Nous nous sommes réunis chaque semaine pendant les six mois passés. Et nous avons fini dans les temps et le budget. D’après les discussions avec nos experts sur le sujet, nous avons une solide recommandation.
Will : Je peux voir que vous et votre équipe avez fait beaucoup de travail. La clé ici, je crois, est de démontrer que votre recommandation améliorera réellement les choses. M. Briscoe a des doutes et moi aussi, sur ce sujet.
Maria : Vous n’avez pas vu notre analyse ? Avant que nous n’ayons commencé ce projet, la métrique était à 48.9 et après que notre recommandation ait été pilotée, la moyenne était 47.05 : C’est une amélioration de 4 %. Avec cette amélioration de 4 %, M. Briscoe peut sans risque réduire son staff de 20 personnes, minimisant ainsi ses dépenses.
Will : Eh bien Maria, je pense que vous avez mis dans le mille. Votre analyse est exactement ce qui empêche M. Briscoe d’être positif sur votre projet. Vos conclusions sont pleines de suppositions qui sont assez risquées.
Maria : Comment pouvez-vous dire cela ? Nous avons les données. Nous avons montré que notre recommandation améliore les résultats de 4 %.
Will : Le problème ici Maria est que vous faites une confusion entre la variation normale dans le processus et l’amélioration réelle. À cause de cela, votre changement de 4 % est simplement un parasite intermittent et pas vraiment un changement durable. M. Briscoe le sait, car il a été formé Six Sigma Ceinture Verte, donc il reste sceptique sur votre analyse.
Maria : De quoi parlez-vous Will ? Nous sommes passés de 48.9 à 47. Qu’est-ce qui est si difficile à comprendre ? De toute évidence, vous ne savez pas ce que vous faites.
Will : Bon, Maria, j’ai pris la liberté de représenter graphiquement vos résultats dans un diagramme de contrôle. Avez-vous jamais entendu parler de diagramme de contrôle ?
Maria : Oui. C’était à l’examen PMP. Je suis certifiée PMP, Will.
Will. Excellent. Donc vous connaissez les causes spéciales et variances de processus. Ce que M. Briscoe recherche est un changement de processus permanent qui prouve que sa métrique majeure s’est en effet améliorée. Le diagramme ci-dessous, basé sur vos données pourrais-je ajouter, montre clairement qu’il n’y a aucune différence après que votre recommandation ait été testée.
Will : Comme vous pouvez le voir, j’ai ajouté une ligne là où vous avez commencé votre essai. Quand vous faites la moyenne auparavant et après, vous obtenez vos chiffres de 48.9 et 47.05. Cependant, quand vous regardez les résultats de la perspective processus, il n’y a clairement pas d’amélioration. La décision de M. Briscoe était assez facile après avoir regardé ce diagramme.
Maria : Mon travail était de finir le projet à l’heure et dans le budget. Je ne suis pas responsable de la métrique de M. Briscoe.
Will : Au bout du compte Maria, la recommandation de votre projet est supposée avoir un impact positif sur cette métrique majeure et c’est tout ce dont M. Briscoe se soucie. Même si vous et votre équipe avez travaillé dur, si la métrique ne s’améliore pas alors implémenter « toute recommandation » est un risque que M. Briscoe n’est pas enclin à prendre.
Maria : Je ne peux pas croire à quel point vous et M. Briscoe êtes entêtés à ce sujet. Pendant les six derniers mois, j’ai dédié ma vie à ce projet. Pas étonnant personne ne veuille travailler sur des projets pour M. Briscoe.
Will : Je peux voir que vous exprimez beaucoup d’émotion sur ce projet Maria. M. Briscoe prend en fait de bien meilleures décisions, basées sur la compréhension des processus, des données et des faits. Juste une suggestion Maria; si vous voulez réussir à obtenir l’adhésion sur vos recommandations dans l’avenir, montrez des données concluantes qui supportent votre point. Montrez un diagramme avec un changement de processus durable comme celui ci-dessous. Si vous pouvez le faire, vous obtiendrez l’adhésion à chaque fois.
Maria : Un changement tel que celui-là semble impossible. Je n’ai pas tant d’autorité ou de contrôle. Et mon travail est de manager des projets, pas de faire des diagrammes.
Will : J’ai un point de vue différent Maria. Souvenez-vous, les dirigeants d’entreprise veulent améliorer la performance de la métrique majeure dont ils sont responsables. Leur approche pour l’amélioration de résultats est à travers les projets. Aussi, les chefs de projet doivent correctement analyser comment les recommandations de leur projet améliorent la performance, sinon, vous rencontrerez de la résistance à chaque fois. C’est exactement où Six Sigma entre en jeu. Je vous suggérerais de prendre le cours de Six Sigma Ceinture Verte Maria. Vous apprendrez comment améliorer les résultats et faire évoluer la métrique dans la bonne direction. Vous serez une meilleure chef de projet.
Maria : Je suis déjà un grand chef de projet. Vous et M. Briscoe ne comprenez tout simplement pas mon analyse.
Will : Oh nous la comprenons Maria, nous la comprenons trop bien.
Here is a method to become a better communicator
How can PMs ensure that their message is better delivered and understood?
The sender-receiver model has been around for a long time. I came across its concepts when I was preparing for the PMP certification proposed by PMI. I have observed over and over again the effectiveness of this model to improve communications regardless of the media used and the contents of the message. So, I’d like to take the time in this article to walk you through it and illustrate it with a few examples from real life to clarify some of its aspects.
The sender-Receiver Model
The communications starts with a message that the source, the sender, wants to convey to the recipient, the receiver, with some assurance that it has been well understood. As you’ll read later on, the second part of the sentence is crucial.
A rapid walk through of the model:
- at one end, the sender is the source of the message
- at the other end, the receiver is the target recipient for the message
- the sender encodes his/her message: this is the encoding step. Basically, he/she translates his/her ideas into a set of symbols that provide the structure in which ideas can be formulated into a coherent and comprehensive message. These symbols could be words (written or spoken), images, pictures…
- the message is the actual output of this encoding process applied to the content emitted by the source
- the media are the means selected to carry across the message. It could be a phone conversation, a face to face session, a memo, an email, a video, a set of slide…
- the receiver decodes the message: the decoding step. The receiver interprets the content based on the set of symbols used by the sender.
- the last step is the feedback one. The feedback is any reaction the receiver may have to the message he/she received.
This model exists since life was born and is not limited to humans. While simple, it carries a number of inherent weaknesses that can be as many barriers to efficient communications.
Potential barriers to efficient communications
differences between sender and receiver- message encoding
- message content
- media
- feedback
Let’s take a closer look at these potential barriers.
Differences between sender and receiver
Language and accent can make the encoding/decoding process very difficult. Even though I consider that my level of English is OK, I had a hard time when working in Scotland for a few months. Not that the Scottish are difficult people, they’re in general lovely, caring and open. However, their accent and some of the terms they use are quite tough to understand for an unaccustomed ear like mine. It took a few repeats and laugh at my own accent for us to communicate effectively. Interestingly, my American colleagues on the team had somewhat similar difficulties.
Cultures, beliefs and values are different. Geographical, ethnic, political, religious, generational and company cultures may differ between the sender and the receiver. This can cause message distortion, misunderstandings, hurt feelings, generate issues where there are none…
Also, the level of education and professional background may not be the same on each side. This does increase the risks of miscommunicating unless the sender is particularly careful to adapt his/her message to the target recipient taking its level of knowledge into account.
Geographical distance between people who know each other well may not be such an issue in communications. But geographically spread projects and distributed teams not seeing each other very often (when at all) is to be taken into account.
Additionally, personality and attitude towards the following areas can vary: Power play, hidden agendas, being in position of authority or not, withholding or volunteering information.
And there are great chances that the work environments/ecosystems are different at both ends of the communication channel: surrounding situation, worries, local issues, personal context, office culture…
Another often underestimated difference is the level of interest one may have in the subject of the communication. What may seem critical to the sender may be mundane to the receiver and his/her span and focus of attention may be very limited towards the message of the sender.
Message Encoding
Language is again an issue and also the choice of symbols. Symbols can easily be sent with one meaning and interpreted with another one: Images, pictures, comparisons, and analogies are not universally understandable.
For example, it’s quite usual in the United States of America to use sports terminology in business. This is not a bad thing to create bond. However, some of these expressions may be totally impossible to understand to foreigners. « We have to hit a real home run with this project! », « I just wanted to touch bases with you on… », « People, what we need here is a touchdown« … Most of these do not translate well outside USA where baseball and American Football are not very popular. Therefore, decoding these will be really difficult for a non native English speaker in France, Spain or Italy.
Similarly, references to Jewish or Christian religions may not be easy to relate with in India, China or Japan. Some pictures can hurt the feelings and reduce comprehension instead of facilitating it.
- In China, green hats mean a man’s wife is cheating on him; it is not a good color for packaging.
- In France studies have indicated green is not a good color choice for packaging either.
- In India green is the color of Islam.
- In Ireland green has religious significance (Catholic).
- In some tropical countries green is associated with danger.
As you can appreciate, the encoding process is not as simple as it may appear at first glance.
Message Content
I’ve learned by trial and error a few rules that may sound basic to some of you:
- seek clarity in the choice of words. Prefer common language to complex or unusual terminology
- use short sentences
- be direct, i.e. to the point, no indirect messages
- avoid negative messages where possible. I would prefer to use « send me a report each month » versus « do not miss reporting each month » which suggest failure to do so as a possibility.
- ban double negative sentences from your message. For example, in the film Mary Poppins, Dick Van Dyke uses a double negative when he says: « If you don’t want to go nowhere… ». You’ll be better served with « If you want to go somewhere… ».
- keep it simple: one message per communication and one question at a time. During my first trip to Japan, I made this mistake. I asked: « should we meet again on Wednesday or Thursday? ». The very polite answer I received was « Yes ».
- avoid unexpressed assumptions. As a sender, if you make any assumption, make it clear to the other party, the receiver. There is a high probability that there assumptions are different from yours.
Media
This could be the sole topic of an entire book. Obviously, all media are not equal nor are they suitable for your message. So, you need to be very selective with the type of media you decide to use depending on the message, the target audience, the context, the cultures…
For example, I think that it is inappropriate to send a communication aimed at addressing a critical problem via email. This type of communication is complex, subject to interpretations, it could hurt feelings and/or self esteem, and it is therefore better handled in face to face communication, video conference or phone meeting as last resource. The lecture of your email may cause lots of frustration and you may not even be conscious of it.
However, in an international context with uneven level of understanding of English, a phone call may not be most appropriate approach unless it is preceded and followed by written messages for clarity and confirmation.
Also, the environment shall be taken into account. Surrounding noise at both ends, quality of the phone line, need for confidentiality to express oneself, relative hierarchical positions of recipients in case you face multiple persons, can each vastly influence the success of you communication.
Feedback
Probably the most critical element of all and often the most neglected one. The sender needs to get and appreciate feedback from the receiver to ensure that the message has been not only transmitted but also fully understood. Communicating in projects (and elsewhere) is never a one way street. Communication has to be bi-directional to be fully effective.
The communication’s process is not complete until you close the loop with the recipient to ensure that he/she has « got » it, i.e. received AND understood.
So, as a sender, you need to look for feedback. Not only expressed by words but also in the gesture, tone of voice (or tone of email) and in attitude. If it does not come naturally, it is your due as the sender to go get it. Feedback may not come spontaneously for many reasons. The receiver is ashamed of asking you to repeat the message, or to look stupid, or doesn’t want to confront you, or to hurt your feelings, or, or, or… On your side, you may feel quite good about receiving no feedback: « who doesn’t disagree agrees »; it’s not challenging you; it’s not showing that you did not express yourself clearly enough to be understood. Please fight this attitude.
Show empathy to the receiver’s needs and always encourage a full duplex communication.
Favoring effective communications
A few things to do:
be clear on the intended results of the communications- one simple and single message at a time
- plan your message taking into account the targeted receiver to maximize his/her chances to fully understand the first time
- select the most appropriate media
- validate and double/triple check that the message has been received and 100% understood
As a teacher once told me about communications: « It is 10% about what you say and 90% how you say it ».
So, careful planning of the symbols, media, non verbal communications and attitude is vital to successful communications.
PMI France met à jour sa plaquette d’information
Les Chapitres Français de PMI ont mis à jour leur plaquette d’information:
- Paris-Ile-de-France (Branches: Auxerre, St Quentin-en-Yveline)
- France-Sud (Branches: Côte d’Azur, Rhône-Alpes, Provence, Midi-Pyrénées, Languedoc-Roussillon)
- Hauts-de-France
- France-Atlantic (Branches: Bretagne, Normandie)
Ils nous rappellent que PMI®, le Project Management Institute, créé en 1969, est une association internationale à but non lucratif dédiée à faire progresser l’état de l’art dans le domaine du management de projet. L’adhésion au PMI® est ouverte à toute personne impliquée ou intéressée dans l’application, la pratique, l’enseignement ou la recherche des principes et techniques du management de projet.
Les Objectifs du PMI®:
- Développer et promouvoir le métier de chef de projet.
- Instaurer le professionnalisme dans le management de projet sur la base de standards, de certifications et la promotion d’une éthique.
- Promouvoir les fondements du management de projet et mettre en avant un « corpus des connaissances » (PMBOK® Guide) pour gérer les projets avec succès.
- Fournir aux membres un forum reconnu de libre échange d’idées, d’applications et de solutions.
- Collaborer avec les universités et les instituts de formation afin d’encourager un enseignement approprié et le développement de la profession.
PMI® fournit des STANDARDS sur le métier
a. PMBOK® Guide – A Guide to the Project Management Body of Knowledge, (4th Edition-2008) – Le corpus des connaissances – une identification structurée, des concepts, connaissances et techniques du management de projet. Ce standard est mis à jour tous les quatre ans. Il est maintenant complété par des documents qui en développent certaines parties : par exemple, Practice Standard for Work Breakdown Structure.
b. The standard for Program Management (2nd Edition-2008)
c. The standard for Portfolio Management (2nd Edition-2008)
d. Organizational Project Management Maturity Model – La base de connaissance, d’évaluation et d’amélioration des organisations (2008)
e. Project Manager Competency Development Framework – Un cadre de développement des compétences du Manager de Projet
Et bien d’autre choses: Un programme de certification à trois niveaux, très largement reconnu dans la profession; des Publications sur le Management de Projet; des chapitres locaux; des séminaires et forums…
PMI France donne également quelques excellentes raisons de rejoindre un chapitre PMI proche de chez vous:
- Avoir des contacts avec des pairs, de différents horizons, dans le management de projet.
- Faire partie d’un réseau de spécialistes du management de projet, dans votre région.
- Obtenir gratuitement un accès à tous les standards du Project Management, du Program Management et du Portfolio Management, en format PDF, y compris le PMBOK® Guide dans plus de 12 langues dont le français.
- Avoir un accès complet, « via l’espace WEB http://www.pmi.org », à plus de 300 livres en format électronique (eBooks) sur le Management de Projet, avec toutes les facilités de recherche par mots clés.
- Découvrir les nouveautés du management de projet à l’occasion des forums organisés par les chapitres
- Rester à jour sur l’actualité du métier. Les chapitres français émettent plusieurs lettres d’information par an.
- Acquérir des points PDUs (Professional Development Units) en assistant aux réunions du chapitre, ou en y présentant des sujets, ceci dans le cadre du renouvellement de votre certification PMP® ou PgMP®.
WEB PMI France: www.pmi-fr.org
10 false ideas about Agile Methods
For once, I decided to translate French articles for our English speaking readers and those of us based in France who work in an international context and would like to share these with our foreign colleagues.
The original articles (2 posts in fact) were published by Renaud Choné on the blog of his company, Time Performance: http://www.timeperformance.com/blog/16-generalites/101-5-idees-fausses-a-propos-des-methodes-agiles
The wide variety of agile methods and their practices generates numerous false ideas on this subject. The object of this article is to demystify the most common false ideas found in the debates on Web by answering these factually.
The arrival of the Agile Methods is generating a ditch between their partisans and those of traditional methods. This rupture is strengthened by the fact that 4 founding principles of the agile methods contradict directly the classic approach:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
( Cf. the Agile Manifesto, the official site: Http://agilemanifesto.org/)
The idea here is not to take position but to allow healthy debates. Indeed, at Time Performance, we are convinced that there is no good method for every situation. And it is moreover why our management of software projects was designed to be flexible while being inspired by the best practices and tools, agile or classic.
False Idea n°1: the Agile Methods apply only to « small » projects
False, forgery and ultra-false… It is nevertheless the most wide-spread idea. It is also the most false.
1) The reason for being of Agile Methods is to allow the project to adapt itself easily to the changes ( » Reponding to changes « ). It makes sense only for the projects of rather long duration, because the risk of change is strong all the more as the project goes on. Furthermore, the duration is necessary to take the full benefits of the heavy investments made in the tests, their automation and the quality of the code, which are at the heart of the agile methods.
Moreover the Agile methods were designed for the development of software products (hence the term of Product Owner which we find in SCRUM), for which the life cycle extends over several years or even several decades.
This false idea was maybe inspired by the brevity of the development cycles. And precisely, an iterative development aims at avoiding the risk of tunnel effect, which is important all the more as the project is long.
Thus the Agile methods are particularly adapted, even recommended, for long projects and not for the small ones.
2) Concerning the size of the team, it is true that SCRUM limits the size of the teams to 8 or 9 individuals, and XP recommends it in practice, because it is the optimal functioning. But nothing forbids establishing several teams which will work each on a sub-project. Moreover SCRUM embeds it with a coordination mechanism which is called the SCRUM of SCRUMs. A team of several dozens of persons can be so constituted.
False Idea n°2: the classification « Agile Method » determines a homogeneous group
The Agile methods are very different from one to another. They are even sometimes almost totally complementary, as XP and SCRUM. If these last 2 methods mark a real break with regard to the classic approach, some as Unified Process establish intermediate steps in the evolution of the methods during the last 20 years.
All these methods agree only on the 4 principles, that is little. Furthermore, the Agile Manifesto offers certain freedom in interpretation. It is thus risky to speak about Agile Methods generally. It is better to speak about practices proposed by such or such method.
On top, it is necessary to add that the implementations of these methods are even more heterogeneous.
False Idea n°3: the Agile Methods are methods of project management
Firstly, the object of the agile methods is software development and not the management of projects. If certain topics of project management are mentioned such as the estimates and the planning, others are plainly absent (for example costs management).
Secondly, the agile methods are not methods. The authors of XP and SCRUM define them as sets of good practices.
False Idea n°4: the Agile Methods are methods of rapid development or prototyping
Short cycles of delivery do not mean that the developments are rapid. It implies simply to validate the progress regularly and concretely.
There are even chances that the developments will be less fast at first with regard to a V cycle, because of the requirements in quality of code and tests coverage, including of numerous re-developments. It is not thus a good approach to use for prototyping.
The Agile projects are marathon runners and not short-distance runners. That is why they travel light. And on the distance, they are generally the fastest and consume less.
False Idea n°5: the agile developments are with difficult to maintain because of the lack of documentation
The fear of seeing the knowledge of the functioning of the software leaving with developers at the conclusion of the project is perfectly justifiable when the documentation is insufficient.
However it is an error to consider that there is no documentation. Following the example of Open Source, in an Agile approach, the main documentation is the source code. And as numerous deliveries are realized throughout the project, everything is made to guarantee a perfect maintainability.
On one hand, the coding rules are very strict and their validation is automated. Several practices at the heart of the Agile methods (the refactoring, the absence of Code Ownership, the Pair Programming etc.) guarantee in the end an appropriate, well designed, legible and well documented source code.
On the other hand, in the source code it is necessary to include the tests (unit, integration, functional etc.). The tests are similar to a document of detailed specifications and an integrated validation tool. It is a significant but indispensable investment for the maintainability and the evolution.
In an agile approach, the source code and the tests stand for respectively detailed design and detailed specification, expressed in natural language in comments and in IT language. The big advantage is to guarantee that the documentation is always up to date with regards to the code, and that the code corresponds to the specifications thanks to the daily tests execution and continuous integration. An agile development should thus be very easy to maintain.
Really, the true question is: « between a complete documentation (specification, analysis, design etc.) and an appropriate and well tested source code which would you choose? »
The agile methods give the priority to the source code and to the tests. The V cycle favors in practice the documents which are generated upstream in the project, to the detriment of the code and the tests situated downstream in the cycle when the pressure to go fast, too fast, is much stronger.
False Idea n°6: the Agile Methods, it is the freedom to do it its own way
Team in « self-management » mode, questioned project manager’s role, redistribution of the responsibilities, the abolition of the contractual aspects, no detailed planning, absence or almost of documents, mainly verbal communication…
All these elements which seduce the teams have a flavor of freedom and emancipation which will frighten more than a manager.
However it would be false to consider that the Agility is synonymic of absence of rules, constraints and structures.
The Agility is above all a change in priority, as demonstrate the 4 principles of the Agile Manifesto. With more distance, it is also a change in the nature of a project, the objectives of which are not any more the respect for a requirements book, at costs and on time.
Now all these changes rest on different organization models which have their own rules.
To be Agile, it is not enough not to apply the former rules, it is especially necessary to apply the new ones.
False Idea n°7: the Agility, it is simple thus it is easy
Following the example of a chess game, the rules of the Agility are simple but their application is not. Several years of practices are needed to master well the game.
The Agility is synonymic of lightness and simplicity. It is natural to see a promise of ease there.
This promise is confirmed by books on Agility. They are generally less thick and less heavy than their equivalents; the principles and the presented concepts are much less numerous and simpler.
To acquire the theory is thus easy, but what about the practice?
In practice, the Agile methods impose very strong requirements on the individuals and the organizations.
For the individuals, there is at first a requirement in technical skills to produce an evolutionary, quality and easy to maintain software, well tested etc. This does not apply only to the Agile methods. The difference is that it becomes a priority with the Agility.
For the individuals, there is then a requirement of behaving and personal discipline to collaborate, communicate, make a commitment, and demonstrate self discipline… It is very difficult to set up Pair Programming; and Daily Scrum can easily turn into chaos.
Some organizations would need almost reorganization. For example, to involve more the business in the development, to redefine the jobs (project manager, scrum master etc.) etc.
For organizations, there is also a problem of the lack of mid-term and long-term visibility with an impact on how projects are budgeted.
Finally, the Agility rests on a strong requirement of Transparency. It can have heavy implications for organizations and individuals. Ken Schwaber, co-author of the Scrum method, expresses with provocation a direct consequence of this transparency strengthened by fast feedbacks: » [the Agility] expose the incompetence « . Stated this way, it makes you think…
In practice, very few teams arrive at the end of an Agile step(initiative). But fortunately, the passage in the Suppleness can be gradually made with immediate gains (cf n°9).
False Idea n°8: the Agile Methods require senior developers
The requirements of Agility on the individuals (cf. N°7) lead to think that the agile methods are reserved for experimented teams, teams of champions of the development. This is exaggerated.
The minimum required by the Agility would be rather a team consisting of an experimented coach and open-minded individuals, capable of questioning, capable of learning and especially who want to progress.
With regard to other methods, an advantage of the agile methods is to facilitate the fast grow in skills of the team members.
How? Simply thanks to the very short iterative cycles which allow fast feedbacks on performance and improving for the following iteration. In SCRUM, it is institutionalized under the shape of a Retrospective at each iteration end.
Besides, practices such as the Pair Programming and the Daily Scrum facilitate largely the transmission of knowledge between the members of the project.
We can retain a principle: the less the team is experimented, the more the « Coach » owes to be.
False Idea n°9: incompatibility with the classic approaches
The agile methods propose practices which, taken separately, are not incompatible with the classic approaches (cascading cycle, CMMI, PMBoK etc.).
For example, it is possible in a cascading cycle to introduce Peer Programming, Retrospect, daily meetings, the Palnning Poker, Burndown charts, continuous integration, the Test Driven… Why not?
If there is incompatibility, it is not at the level of the practices, but rather at the level of the values.
False Idea n°10: the Agility can apply to anything and everything
When, to test its software, it was necessary to reserve several days in advance some machine processing time on the central server and print its software on punch cards, the Agility and its Test Driven and Continuous Integration would have made anyone laugh out loud
To be Agile, it is necessary to have the will but also the means.
In domains, as construction or industry *, the constraints certainly do not allow to be as agile as in the software development.
In a project at fixed price, a purely agile approach is inconceivable. It is inevitably necessary to fix the perimeter.
In a deployment project, the Agility may bring more inconveniences than advantages.
To be able to be Agile, the change has to be desirable but also possible at low-cost. That is why the software development is the privileged domain of the Agility.
* In the industry, there is a Lean Manufacturing. This approach shares some of the values and objectives of the Agility, but with different practices oriented towards the industry.
back to basics: responding to resistance
In a previous post, I wrote about the basics for running an effective call. In this article, I’d like to focus on some of the basics for responding to resistance during calls or meetings, especially when you’re selling a project or an idea. Again, this is certainly nothing new for experienced PMs or sales professionals. But what goes well without saying, goes even better when you say it.
I learned that there are essentially three different types of resistance that need to be recognized and managed: Misperception, Skepticism and Concern. Actually, the way to respond is not so different but let’s see the three cases:
1. Misperception
To misperceive is to perceive incorrectly or misunderstand. You are in a situation where you have exposed your point and then listened actively to your counterpart. And you notice that the message you are trying to get through is not understood. This could be due to many reasons: the way you expressed it; preconceived ideas or lack of listening on the other side; too complex to be understood in one shot; requiring prerequisite knowledge that the other person may not have… What is required in this situation is first of all to acknowledge the misperception, then provide clarification and conclude with listening again and probing for acceptance.
- acknowledge the misperception: prove by repeating as much as possible the words of the person that you acknowledge the fact that there is a misperception. Make it clear that the fault is yours. The misperception or misunderstanding has happened because you have not been able yet to convey your message clearly enough to convince the person.
For example: « I hear you say that you understand that this project will last 2 years and require 10 internal staff members. I have not been clear in my explanations and I’d like to clarify this very specific point. »
provide clarification on the piece that has not been well understood.
In our example: « The project would indeed last 2 years and 10 resources with the currently defined scope. However, one option I presented is to resource with a 50/50 split between internal and external. Also, you have the second option I mentioned of reducing the initial scope to get the bulk of the benefits in a shorter timeframe if you believe this is feasible. »
- and conclude with listening again and probing for acceptance.
In our example: « I saw you nod your head when I clarified that we could staff the project with 50% of external resources. Are we in agreement that this option is a good approach to build upon for the project? »
2. Skepticism
Skepticism very often means doubts and desire to suspend judgment on new information that is not very well supported by argument or evidence. When you notice that the information you provided is not well accepted and that it is not due to a misunderstanding but rather skepticism, you are in a situation that requires assurance or reassurance. I.e. acknowledge the skepticism, then provide assurance and conclude with listening again and probing for acceptance.
- acknowledge the skepticism: you will often have anticipated this potential reaction as you reviewed your proposal or speech. You did put yourself in the shoes of your counterpart for a moment and tried to see from his eyes what could be doubtful with your project or idea you’re selling. In other instances, you can recall the times when you were not familiar with the project or idea and potentially shared similar doubts. Use these to show that you understand the skepticism of your counterpart.
For example: « I see that you seem to have doubts with the 2 years and 240 man month effort. To be honest, it was also my first reaction when I saw these estimates.«
- provide assurance on the piece that is generating skepticism. If you can, provide more facts and evidence that the information you provided is certain. Industry benchmarks or studies, figures from prior projects, references (especially from persons your counterpart knows well), track record, statistics,… are as many sources you may want to use to assure the person on the topic.
In our example: « So, I challenged the team to understand the details. And, they were able to show me the figures from a prior project of similar complexity and scope that had cost 360mm with 12 resources over 2.5 Years. Thanks to that earlier experience, they were able to reduce the duration of our project to 2 years and the team size to 10 resources instead of 12. A 30% improvement with a team that has already undertaken a similar challenge! »
- and conclude with listening again and probing for acceptance.
In our example: « You appeared to be in tune with me when I exposed the way the estimates were built. Are you more comfortable with this aspect of the project? »
3. Concerns
« I have a concern… » is the traditional method of bringing up an issue to a meeting. It is a very strong statement and if unsettled a concern about something will stop it from being done. If your counterpart is not expressing his concerns openly but you can tell that there is a real issue for him or her that is not being addressed, ask the question. « In your opinion, what is the key issue or concern with the proposed project that we shall address? ». Again, what is required in this situation is first to acknowledge the concern, then to reaffirm the strong points of your proposal, seek resolution and conclude with listening again and probing for acceptance.
- acknowledge the concern: make sure that you understand the exact concern. Is it cost, time, contents, approach, staffing, skills, payment terms? Prove by repeating as much as possible the words of the person that you have really understood where the concern is.
For example: « I hear you mention as a concern the fact that the project will last 2 years and require 10 internal staff members. And that the duration is a real issue for you because your window of opportunity is 18 months to bring the new services to the market. »
- reaffirm the strong points of your proposal and use established agreements to reinforce the foreseen benefits. Restate the needs/benefits equation for the project.
In our example: « This new project is absolutely required to enable the company to deliver these new services and earlier studies have established that amendments to existing solutions would cost more and take longer. Additionally, we are in agreement on the scope of the project in terms of contents and resources required to achieve it. The project will enable the new services to be developed and operated efficiently. »
seek resolution looking for solutions with your counterpart that would remove his concerns.
In our example: « The project will indeed last 2 years and 10 resources with the currently defined scope. However, an option we looked at is to reduce the duration by bringing extra resources to run in parallel some tasks that are currently planned sequentially. Also, we have the option I mentioned earlier to reduce the initial scope to focus on very critical functionality that will get you the bulk of the benefits in 18 months with some manual processes while developing the full functionality in the next release. »
- and conclude with listening again and probing for acceptance.
In our example: « I saw you nod your head when we rediscussed the option to add external staff the project. Are we in agreement that this is a good approach to move forward on the project? »
Of course, PMs are not professional sales people, but mastering the basics for responding to resistance during calls or meetings is a very useful asset in our professional and personal life.
les leçons apprises, cela n’intéresse personne !
C’est sous ce titre volontairement provocateur que j’ai écrit un article dans lequel je propose une approche pour partager efficacement les expériences de Management de projet.
Pour progresser, les erreurs passées ne seront pas répétées alors que les succès deviendront une partie intégrante de notre manière de travailler. Cela semble tout à fait raisonnable, je l’espère. Cependant, peu d’entre nous y dédient l’attention requises. Voici une proposition pour essayer de changer cette situation.
Avez-vous d’autres approches réussies à proposer ?
lessons learned, nobody cares !
I posted on Orange Business live the following article about a proposed framework to share lessons learned in the Project Management area.
In order to progress, past errors shall not repeat while past successes must become an integral part of our way of working. This sounds quite reasonable I hope. However, we often do not allot sufficient quality time to learn from past experience. How can we improve in this Experience Sharing exercise?
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.
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 :
- Recueil des besoins et rédaction du cahier des charges
- Analyse fonctionnelle
- Développement du code
- Intégration
- Test et mise au point
- Installation
- 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 :
- 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.
- 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.
- La construction, où le logiciel est construit et testé et la documentation de support est produite.
- 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.
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. »
le management par l’écoute et la rencontre pour les chefs de projet (MBWA)
Voici un rappel intéressant d’une méthode qui n’a rien de nouveau et n’a pourtant pas perdu en efficacité dans le monde du web 2.0 où règnent les relations virtuelles.
Original article in English by Kareem Shaker, Dubaï, Émirats Arabes Unis.
Traduction personnelle et approximative:
Vous ne pouvez pas gérer les gens depuis une tour d’ivoire, vous devez interagir avec votre équipe, parler avec eux tous les jours et faire tomber une barrière qui peut être un élément important de démotivation dans beaucoup d’organisations. Le management par l’écoute et la rencontre (Management By Wandering Around/MBWA en Anglais) est une technique simple mais efficace pour créer et maintenir un lien solide avec votre équipe qui soit bâtit sur la confiance mutuelle, la compréhension et l’accord.
MBWA est une des techniques les plus efficaces à pratiquer sur le lieu de travail et beaucoup de managers l’utilisent pour envoyer un message silencieux “je suis ici!” aux membres du personnel. Je suis certain que vous l’avez déjà expérimenté lors de votre carrière professionnelle. Alors que vous étiez assis et totalement absorbé par votre écran, soudainement, vous avez trouvé le grand chef (l’HIPPOPOTAME) de votre organisation debout à deux ou trois mètres de vous et il vous a demandé “qu’essayez-vous de résoudre ?!”
Cela s’appelle le management par l’écoute et la rencontre, cela semble très simple et n’exige aucune compétence spécifique. Pourtant, c’est très efficace et c’est l’une des meilleures techniques de motivation que vous puissiez utiliser. En tant que chef de projet qui doit rester en contact avec les gens, vous devez comprendre leurs problèmes et les aider à les résoudre. Dans cet article, je donnerai à quelques façons de commencer à pratiquer le MBWA. L’essayer c’est l’adopter, et vous percevrez certainement la différence. Cet article s’adresse particulièrement aux chefs de projet mais il peut aussi aider les managers de tous les niveaux à la pratique du MBWA.
Réunions Quotidiennes Debout
C’est un des thèmes principaux de Scrum, cependant, en pratiquant le MBWA, la réunion debout (« standing meeting ») n’a pas besoin d’être quotidienne. Ce peut être simplement une réunion rapide pour faire le point avec l’équipe des problèmes, progrès, statut, et ainsi de suite. La beauté des réunions debout est ce que cela peut sembler spontané et non prévu. Vous pouvez dire à l’équipe: “faisons la réunion d’aujourd’hui debout, nous serons ensemble pendant 10 à 15 minutes et parlerons du projet”. Il n’est pas nécessaire d’utiliser Scrum pour avoir une réunion debout. En fait, elle peut éliminer la lassitude vis-à-vis des réunions habituelles où trop de temps est gaspillé. Vous n’êtes pas forcé au formalisme pendant la réunion, utilisez des mots qui motivent et remerciez l’équipe de chacun de leurs petits accomplissements (pour exécuter des réunions efficacement, lisent mon article: Better Meetings.)
Les prendre sur le vif alors qu’ils font quelque chose de bien
Un des aspect de la technique dite « The One Minute Manager » développée par Kenneth H. Blanchard est de surprendre les salariés pendant qu’ils font quelque chose de bien pour le projet, même petit, et de les remercier de le faire. Cela motivera tous les membres de l’équipe et augmentera leur niveau de productivité. Si vous passez devant un membre de l’équipe qui fait quelque chose de bien, remerciez-le et exprimez votre satisfaction de le voir faire les bonnes choses, cela stimulera toujours les membres de l’équipe à bien travailler et à améliorer les livrables du projet. Donc, ceci améliorera l’organisation toute entière.
Présentez les membres inconnus de l’équipe aux Clients
Il arrive souvent que vos clients ne soient pas conscients de toute l’équipe projet. Ils peuvent interagir avec le leader d’équipe, et à peine connaître les développeurs. Vous pouvez utiliser la première réunion dans les locaux de l’équipe pour une visite des clients sur le lieu de travail et leur présenter les membres de l’équipe en expliquant leurs rôles et responsabilités. Ceci est un réel motivateur.
Posez des Questions Rafraîchissantes
Les questions ne devraient pas être liées au projet. Vous devrez socialiser avec l’équipe et mieux connaître leurs centres d’intérêt, passe-temps, familles, soucis, et ainsi de suite, vous pouvez utiliser n’importe laquelle des questions suivantes (remplacer les mots en italiques):
- Comment était votre week-end ?
- Comment est votre déplacement pour venir au bureau? Combien de temps dure-t-il?
- Avez-vous vu le film d’Avatar ou Milan AC contre Inter Milan ou le show d’Oprah ?
- Avez-vous lu le dernier livre de Dan Brown ?
- Avez-vous essayé la version bêta de Microsoft Office 2010 ? (Donnez-leur indirectement des astuces pour stimuler leur connaissance)
Claironnez les Bonnes Nouvelles
Rien ne motive l’équipe comme les bonnes nouvelles. Essayer d’utiliser les bonnes nouvelles même petites pour faire plaisir à l’équipe. Allez dans leurs bureaux et dites haut et fort “Mesdames, Messieurs, j’ai quelques bonnes nouvelles, NOUS …”. N’oubliez pas d’utiliser « NOUS » et abstenez-vous d’utiliser « JE ».
Récapitulatif
MBWA est une technique puissante à utiliser par l’encadrement, les directeurs, managers et chefs de projet. C’est l’une des caractéristiques d’un manager qui réussit. Ce doit être nourrit et appliqué savamment, et aussi pratiqué spontanément. Cependant, si vous vous n’avez pas envie de l’utiliser, ne vous forcez pas, car s’il est utilisé à tort il démotivera les membres de l’équipe et aura un effet contre-productif. Vous devrez le faire de manière rapide et ne pas y dépenser trop de temps à marcher autour d’eux et ne pas leur laisser penser que vous vérifiez ce qu’ils font!
Partagez votre Expérience
Si vous utilisez le MBWA et avez d’autres techniques qui marchent bien pour vous, ou si vous avez utilisé quelques techniques qui n’ont pas fonctionné avec vous, partagez s’il vous plaît votre expérience et laissez un commentaire!
