Voir l’article de Jean-Claude Grosjean sur le sujet: Scrum Guide 2013: le Product Backlog Refinement à l’honneur!
La version de Juillet 2013 en ligne du Scrum Guide de Ken Schwaber et Ken Sutherland (auteurs de Scrum).
version 2013 du Scrum Guide
Catégorie : outils et méthodes
7 définitions de Big Data intéressantes à connaître
7 Definitions of Big Data You Should Know About
http://timoelliott.com/blog/2013/07/7-definitions-of-big-data-you-should-know-about.html par Timo Elliott
Face à la confusion actuelle sur la terminologie de ‘Big Data’, voici un guide pratique – et quelque peu cynique – de certaines des définitions clés que vous pourriez trouver.
La première chose à noter est que, malgré ce qu’en dit Wikipédia, tout le monde dans l’industrie reconnaît généralement qu’avec le Big Data il ne s’agit pas d’avoir plus de données (puisque ceci est juste inévitable et ennuyeux).
(1) Le Big Data Original
Big Data comme les trois Vs : Volume, Vitesse et Variété. Ceci est la définition la plus vénérable et célèbre, donnée d’abord par Doug Laney de Gartner il y a plus de douze ans. Depuis lors, beaucoup d’autres ont essayé de l’élargir à 11 V avec entre autres Validité, Véracité, Valeur et Visibilité.
(2) Big Data comme Technologie
Pourquoi un terme vieux de 12 ans a-t-il soudainement grossi sous les projecteurs ? Ce n’est pas simplement parce que nous avons maintenant beaucoup plus de volume, vitesse et variété qu’il y a une décennie. Il a plutôt été alimenté par de nouvelles technologies et en particulier la croissance rapide de techniques de code en open source comme Hadoop et autres NoSQL façons de stocker et manipuler des données.
Les utilisateurs de ces nouveaux outils ont eu besoin d’un terme qui les différencie des techniques précédentes, et ce sont arrêtés sur le terme très tristement inadéquat de Big Data. Si vous allez à une grande conférence Big Data, vous pouvez être assurés que des sessions parlant de bases de données relationnelles, peu importe à combien de Vs elles répondent, seront minoritaires.
(3) Big Data comme Différenciation dans les Données
Le problème avec « Big Data comme une technologie » est que (a) c’est assez vague pour que tous les vendeurs de l’industrie se soit empressé de le revendiquer pour eux et (b) tout le monde ‘savait’ qu’ils devraient élever le débat et parler de quelque chose de plus orienté business et utile.
Voici deux bonnes tentatives pour aider les organisations à comprendre pourquoi le Big Data de maintenant diffèrent du Big Data du passé :
- Transactions, Interactions et Observations de Shaun Connolly de Hortonworks. Les transactions composent la majorité de ce que nous avons rassemblé, avons stocké et avons analysé dans le passé. Les interactions sont les données qui viennent de choses comme les clics des gens sur des pages Web. Les observations sont des données collectées de manière automatique.
- Process-Mediated Data, Human-Sourced Information, and Machine-Generated Data de Barry Devlin, qui a co-écrit le premier papier sur le « data warehousing » . C’est essentiellement le même que ci-dessus, mais avec des noms plus clairs.
(4) Big Data comme Signaux
Ceci est une autre approche orientée business qui divise le monde selon l’intention et le cadencement plutôt que le type de données, avec l’aimable autorisation de Steve Lucas de SAP. ‘ L’ancien monde ‘ est à propos de transactions et au moment où ces transactions sont enregistrées, il est trop tard pour faire quoi que ce soit d’elles : les sociétés ‘managent constamment dans le rétroviseur’. Dans ‘le nouveau monde’, les sociétés peuvent au lieu de cela utiliser de nouvelles données ‘de signal’ pour anticiper ce qui va arriver et intervenir pour améliorer la situation.
Les exemples incluent le suivi de la perception des marques sur les médias sociaux (si votre nombre de ‘likes’ diminuent abruptement, vos ventes suivront sûrement) et la maintenance prédictive (des algorithmes complexes déterminent quand vous devez remplacer une pièce d’un avion, avant que l’avion ne coûte cher, scotché sur la piste).
(5) Big Data comme Opportunité
Celle-ci est de Matt Aslett de 451 Research et définit largement Big Data comme ‘l’analyse des données qui étaient précédemment ignorées à cause de limitations technologiques.’ (OK, donc techniquement, Mat utilisé le terme ‘Dark Data’ plutôt que Big Data, mais c’est assez proche). Mon favori personnel, puisque je crois qu’il s’aligne le mieux sur comment le terme est utilisé dans la réalité dans la plupart des articles et discussions.
(6) Big Data comme Métaphore
Dans son merveilleux livre The Human Face of Big Data, le journaliste Rick Smolan dit que Big Data est « le processus d’aider la planète à cultiver un système nerveux, celui dans lequel nous sommes juste un autre type de capteur, humain. » Profond, euh ? Mais d’ici que vous ayez lu certaines des histoires dans le livre ou sur l’application mobile, vous hocherez la tête en signe d’accord.
(7) Big Data comme Nouveau Terme pour Vieux Truc
Ceci est l’utilisation la plus paresseuse et la plus cynique du terme, où les projets qui étaient de technologie précédente et auraient été appelés Business Intelligence (BI) ou l’analytique dans le passé ont soudainement été rebaptisés dans une tentative assez flagrante de sauter sur le train en marche du Big Data.
Et finalement, en bonus, une assez inutile définition de Big Data. Toujours pas assez pour vous ? En voici 30+ de plus et ça continue !
Le résultat : indépendamment des désaccords sur la définition, tout le monde convient d’une chose : le Big Data est important et amènera d’énormes nouvelles opportunités dans les années à venir.
pensons Produit Minimum Viable (MVP)
MVP Thinking
http://brodzinski.com/2013/06/mvp-thinking.html par Pawel Brodzinski
Un des buts atteints par Eric Ries’ Lean Startup’ et porteur du plus de valeur est de populariser le terme de « Minimal Viable Product » (MVP), ou Produit Minimum Viable en français. Bien sûr le concept n’est pas nouveau. Nous utilisions l’idée de « Minimal Marketable Feature » (MMF) depuis les tous premiers jours de Kanban et elle était basée sur la même façon de penser. Il y a aussi davantage de concepts similaires.
La prémisse de base est que nous devrions construire la chose la plus petite possible ou faire fonctionner l’expérimentation la plus petite possible qui reste raisonnable et ajoute de la valeur. Selon le contexte la valeur peut être quelque chose qui aide des utilisateurs, mais peut aussi être simplement la découverte de nouvelles connaissances ou la vérification d’une hypothèse.
Une chose que j’ai réalisée récemment est à quel point j’applique largement cette pensée. Initialement, c’était simplement la façon de décomposer le contenu. J’ai voulu que mes équipes construisent des morceaux de logiciel probablement petits, mais toujours de valeur, et qu’un client puisse donc vérifier et nous donner un retour avec des informations utiles. Alors, après Lean Startup, il s’agissait de faire fonctionner un produit. Ce que nous voulons construire est quelque chose de nouveau qui frappe les esprits. Quelle est la fonctionnalité la plus petite qui peut prouver ou réfuter l’hypothèse que cela puisse fonctionner ?
D’une façon ou d’une autre j’utilise maintenant la même façon de penser, la pensée MVP si vous voulez, pour discuter des idées de marketing, définir des plans d’action pendant des rétrospectives, etc. Souvent il est difficile de définir un produit en soi, mais il y a toujours une idée des résultats attendus et un effort minimal définissable permettant d’obtenir ce résultat.
Ainsi comment définirais-je la pensée MVP ?
1. Définir le plus petit prochain objectif de valeur que vous voulez réaliser.
2. Définir l’effort minimal qui vous permettra d’atteindre ce but.
3. Exécuter.
4. Analyser les résultats et apprendre.
5. Itérer.
Une partie potentiellement délicate est la définition de l’objectif parce que c’est totalement contextuel. C’est aussi quelque chose qui me plaît vraiment car je n’aime pas les recettes toutes prêtes. En fait, s’il y a quoi que ce soit de nouveau ici, c’est essentiellement l’application extrêmement large du modèle car l’idée elle-même n’est pas nouvelle. Je veux dire, nous limitons d’habitude notre contexte de travail au périmètre d’un projet, au management d’un produit, à faire tourner une affaire, etc. Alors, nous inventons un nouveau terme et s’il marche nous en faisons nos carrières de consultants excessivement bien payés.
Ce n’est pas du tout mon but. J’essaye juste d’élargir un contexte applicable d’idées que nous connaissons déjà et que j’ai personnellement trouvées utiles.
résolution de problème
Donc si mon problème est une fuite sous le toit près d’une lucarne, mon objectif minimal suivant peut être de vérifier si la fuite a un rapport avec un volet externe. Un tel objectif est acceptable parce que l’effort minimal peut être simplement d’attendre l’averse suivante avec le volet ouvert ou fermé. Je ne me précipite certainement pas pour réparer le toit.
marketing
Si nous parlons de marketing ? Donnons un objectif général, disons: TechCrunch parlera de nous. Quelle serait l’expérimentation de valeur la plus petite qui pourrait nous rapprocher de la réalisation de cette sorte d’objectif ? Je suppose qu’étendre et manager son réseau peut être une première étape très raisonnable. Cela n’exige même pas d’avoir une idée, sans parler d’un produit, que nous voudrions voir couvert.
développement de produit
Que diriez-vous d’un produit ? Eh bien, celui-ci a été couvert pratiquement partout. Construire la fonction minimale, probablement même une simulation, qui permet de vérifier que l’idée pour le produit a du sens.
leçons apprises
Rétrospectives ? Quel est le simple, plus petit possible, changement qui aura un impact positif sur l’équipe ? Essayez-le. Vérifiez-le. Répétez.
achats
Zut, j’achète même mon équipement de marin de cette façon. Quel est le plus petit jeu d’équipements possible qui donne une chance de survie raisonnable ? Puis, j’utilise le résultat et je réitère, par exemple la prochaine fois j’aurai besoin de nouveaux gants, de caleçons longs et de protection imperméable pour un téléphone.
Quand vous y pensez c’est essentiellement du Kaizen – faire systématiquement de petites expériences d’amélioration partout. Alors oui, il n’y a rien de nouveau. C’est seulement l’idée spécifique de Produit Viable Minimal qui me parle personnellement et m’a donné une contrainte agréable qui peut être utilisée dans les différents domaines de ma vie.
À propos, malgré sa définition très ouverte je trouve aussi que Kaizen est d’habitude appliqué dans un contexte très limité. Aussi, peu importe quelle idée marche pour vous, souvenez-vous juste que vous pouvez l’utiliser dans un contexte beaucoup plus large.
Free Agile Charts by Scrumage
I’ve bumped across the attached charts produced by Scrumage that you may find useful for your Agile projects:
- Excel Agile Charts: http://scrumage.com/blog/2013/04/agile-charts-for-ms-excel/
- Classic Agile Charts: http://scrumage.com/blog/2012/10/free-agile-chart-templates/
- Google Spreadsheet Templates for the Management of Agile Projects: http://scrumage.com/blog/2012/08/agile-charts-part-2/
Have a look and let us know if these are useful and if you have others to share.
Here is a method to become a better communicator (R)
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.
free MS Project 2013 webcast series coming up
Ready to learn more about Microsoft Project and how it can can help you get more out of your projects?
The new Project offers flexible service or on-premises solutions for project portfolio management and everyday work, enabling you to effectively execute winning projects and achieve strategic priorities.
Now’s the time to register, attend these free Project webcast series, and find out more about Project 2013.
REGISTER
Big Data, encore et encore… si vous êtes chef de projet dans l’IT difficile de ne pas en entendre parler !
En parallèle aux célèbres nuages du Cloud, nous entendons de plus en plus parler du « Big Data ».
Le PMI en fait d’ailleurs sa page de couverture et thème principal du PM Network du mois d’août.
Voici quelques pointeurs qui vous permettront de percer les nuages du Big Data!
Tout d’abord une video TED, sous-titrée en français (sélectionner French dans caption) reprend l’historique et les grands principes:
Passons maintenant à une présentation à TEDx du Dr. Kirk Borne qui est un scientifique et astrophysicien. Après 20 ans à travailler pour la NASA, il changea de route et se spécialisa dans l’analyse des données, un domaine qui devint le ‘Data Mining’ et plus récemment appelé « Big Data ». Son speech couvre certains des principes de base du « data mining » et comment ceux-ci nous influencent chaque jour. Sous titrage en anglais seulement mais Dr Borne est facile à comprendre car habitué à enseigner.
Enfin une vidéo montrant toute la puissance (un peu effrayante!) du Big Data…
free download – Managing Change in Organizations: A Practice Guide by PMI
Change Management
All strategic change happens through programs and projects.
Projects and programs by their nature create change, and sophisticated organizations know strategic change happens through projects and programs. Project, program and portfolio managers who want their organizations be successful need the skills to manage change front and center in their talent portfolio.
To answer this growing need, PMI has launched Managing Change in Organizations: A Practice Guide – currently available for free download for a limited time only. This guide helps project and program managers successfully identify change elements and account for them within a project/program plan. It also helps create clear and powerful strategies to guide organizational development, including a means of executing those strategies reliably and effectively.
Not a separate role or function, change management is a skillset for project practitioners that bridges leadership, business acumen and technical skills. The guide is the culmination of PMI’s 20 years of thought leadership in change management and is the definitive guide to help you lead a proactive, planned approach to change.
Take an in-depth look at change management practices embedded in PMI’s foundational standards. It is a practical resource for effective change management in projects and programs.
For a limited time, download a free PDF of the Guide (a US$34.95 value).
Respecter ses délais en projet, c’est possible ! Par Isabelle ICORD
Isabelle ICORD, Fondatrice et directrice de Pro CC (http://www.procc-conseil.com) a 20 ans d’expérience en pilotage de projets internationaux de développement en entreprise. Experte de la pratique de la Chaîne Critique et à l’origine des toutes premières implémentations pratiques de ce concept en France, avec d’une expérience récente et réussie de mise en œuvre chez e2v semi-conducteurs Grenoble. Auteure d’un programme complet de formation vidéo sur la CCPM Boost Project System.
Ne croyez pas que parce que les enquêtes montrent qu’en moyenne, plus de 70% des projets sont en retard, cela doit être une fatalité !
Maîtriser ses engagements projet, c’est savoir piloter ses projets et en particulier manager les aléas qui inévitablement viendront perturber leur exécution et de fait l’ensemble du portefeuille auquel ils appartiennent.
Pour cela, la Chaîne Critique est une pratique innovante et efficace, qui permet non seulement de gérer les impondérables, mais également de réduire la durée des projets, d’optimiser l’allocation des ressources et, au final, de faire périodiquement plus de projets sans avoir plus de moyens. Couplée à une démarche rationnelle de sélection de “bons projets” et de constitution d’un portefeuille aligné à votre stratégie, vous avez en main tous les atouts pour valoriser vos développements, vos produits, vos transformations et vos changements.
La Chaîne Critique peut se résumer simplement en 3 règles.
La première concerne le portefeuille de projets : bien souvent les organisations veulent mener de front plus de projets qu’elles n’en sont capables et vont d’elles-mêmes engorger leur système.
A force de tout commencer au plus tôt en croyant que l’on aura ainsi plus de chance de finir tôt, l’ensemble des projets est ralenti à tel point que, parfois, il n’y a plus de temps pour finir. Hors un projet a de la valeur lorsqu’il est fini, rarement lorsqu’il démarre. Aussi est-il pertinent de savoir cadencer le démarrage des projets suivant la capacité réelle de l’organisation à faire, et en particulier à finir. Sérialiser les projets, c’est bien souvent diminuer l’encours pour être plus rapide sur chacune de nos transformations.
C’est donc arriver à réduire le temps de cycle des projets en focalisant l’effort et en augmentant l’efficacité. L’idéal est de pouvoir cadencer le début du projet par rapport à l’équipe qui est la plus contrainte dans l’organisation, c’est à dire une équipe clé qui, naturellement la plus chargée, sera la première à ralentir l’ensemble.
La deuxième règle de la Chaîne Critique nous apprend à mieux gérer nos sécurités en temps dans le projet
Plutôt que de mettre de la sécurité dans l’estimation de la durée de chacune des tâches constituant le projet (pour se protéger desdits aléas), mieux vaut mutualiser au niveau du projet l’ensemble de ces marges de sorte que la marge globale nécessaire est moins importante que la somme individuelle des marges (principe même de mutualisation).
Ce système présente aussi l’énorme avantage de savoir cumuler les avances au même titre que le sont les retards.
Car en planification traditionnelle, les sécurités locales sont bien souvent gaspillées du fait même de nos comportements humains. Soit nous présentons le “syndrome de l’étudiant”, qui commence au plus tard son travail (et non pas au moment où on lui donne) et gaspille donc sa sécurité au démarrage, soit nous suivons la “loi de Parkinson” qui consiste à occuper tout le temps qui nous est imparti pour faire notre tâche.
Dorénavant, pensons à planifier nos projets avec une sécurité globale et explicite qui protège le projet et non chacune des tâches, l’important étant bien de finir le projet à l’heure et non pas de finir toutes les tâches à l’heure.
La troisième règle s’applique en exécution : nous allons piloter le projet en mesurant la vitesse d’exécution de sa chaîne critique au regard de la vitesse à laquelle il consomme sa sécurité.
Chaque projet peut donc facilement et à tout moment justifier de sa santé objective :
• vert : tout va bien, le projet avance plus vite qu’il ne consomme de marge
• orange : alerte, la marge est consommée et la tendance s’inverse
• rouge : action, la tendance est mauvaise, il faut réagir car la marge diminue trop vite au regard de l’avancement de la chaîne critique
Chaque tâche de tous les projets hérite donc naturellement d’un indice de priorité, dynamique, objectif, cohérent qui permet instantanément d’ordonnancer l’exécution des tâches et d’allouer efficacement les ressource, en particulier lorsque des arbitrages sont nécessaires.
Le système dans sont ensemble est optimisé car la vision globale de tous les projets en mode Chaîne Critique permet d’arbitrer un portefeuille et de concentrer les décisions d’un comité de direction sur les projets qui visiblement sont en souffrance.
Si la Chaîne Critique est un indéniable avantage au pilotage de projet et portefeuille, encore faut-il savoir constituer ce portefeuille des projets pertinents et en phase avec la stratégie en place.
Cette vision des “bons projets” est structurée par une démarche SMP2. Savoir bien faire les bons projets, que demander de plus ?…
La gouvernance est une science complexe ! Plusieurs référentiels ou modèles de maturité sont à la disposition des Directions qui souhaiteraient mettre sur une même page leurs ressources, leurs visions de l’organisation et des transformations. SMPP, porté par la Communauté (SMP2®) (experts, démarche et outils dédiés au déploiement du référentiel SMPP) est l’un d’entre eux.
les cinq forces de la compétitivité de Michael Porter sont plus que jamais d’actualité
J’ai apprécié cette interview vidéo d’une douzaine de minutes de Michael Porter. Michael Porter est un professeur de stratégie d’entreprise de l’Université Harvard qui célèbre pour ses études sur la façon dont une entreprise peut obtenir un avantage concurrentiel (ou avantage compétitif) en maîtrisant mieux que ses rivaux les forces qui structurent son environnement concurrentiel. Il a publié un papier en 2008 chez Harvard Business Review qui actualise sa théorie « Les cinq forces de Porter » (http://fr.wikipedia.org/wiki/Cinq_forces_de_Porter) datant des années 80.
J’avais déjà à l’époque beaucoup apprécié sa synthèse des facteurs qui influent sur la performance d’une entreprise selon cinq forces :
- le pouvoir de négociation des clients ;
- la menace de nouveaux entrants potentiels ;
- le pouvoir de négociation des fournisseurs ;
- la menace de produits de substitution ;
- l’intensité de la concurrence intrasectorielle.
De plus, ces cinq forces peuvent être utilisées de manière plus personnelle car elles expriment également toute leur puissance lorsque vous les appliquez à vous même, à votre job, à votre contribution dans l’entreprise quelque soit votre occupation:
- quel est le pouvoir de mes clients, mon employeur, mon manager… ?
- quel nouveau venu pourrait prendre mon job ?
- quel est le pouvoir de négociation de mes fournisseurs sur le projet, des membres de mon équipe ?
- existe-t-il d’autres solutions à ma contribution pour l’entreprise, ma fonction pourrait-elle par exemple être externalisée ou sous-traitée ? un nouveau « business model » pourrait-il rendre mes services inutiles ou dépassés ?
- au sein de l’entreprise ou de l’organisation, quel autre chef de projet pourrait aisément, voire avantageusement, me remplacer ?
la structure de découpage du projet (Work Breakdown Structure: WBS) par Philip Diab (R)
The Work Breakdown Structure (WBS) par Philip R. Diab
Si je devais identifier un seul outil/méthode/processus qu’il faut maîtriser parfaitement pour les chefs de projet, ce serait la structure de découpage du projet (WBS). Encore, je suis toujours stupéfié que dans certains des ateliers de travail poussés que je conduis sur la gestion de projet très peu de praticiens comprennent ce qu’est un WBS et comment développer un bon WBS qui aidera dans la planification de projet.
Heureusement, cette semaine j’enseigne « les essentiels du management de projet » donc mes attentes du savoir des participants sur le WBS sont assez faibles. C’est l’un des sujets que j’essaye de ne pas couvrir à toute vitesse, même si cela signifie que je déborde le temps qui lui est imparti dans l’agenda de l’atelier. L’endroit où je commence d’habitude est par la définition standard du WBS selon le PMBOK, qui expose :
“A deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project.”
Dans la communauté de management de projet il y a deux vues du développement de WBS. Un groupe se concentre sur l’identification des tâches qui sont nécessaires à accomplir sur le projet. Ce que cela signifie est qu’ils aiment identifier tous « les verbes » associés au projet. Dans ce cas, l’argument est qu’en identifiant les activités, on est capable de produire l’échéancier à partir du WBS. Dans certains outils de planification, il y a même une option pour produire une vue imagée de l’échéancier comme un WBS.
Il y a un autre groupe qui est concentré sur l’identification de tous les livrables qui doivent être produits par l’équipe projet. Ce que cela signifie est qu’ils identifient tous « les noms » associés au projet. Je suis un partisan de cette dernière vue. En travaillant sur la définition de tous les livrables, nous sommes capables de produire une liste des éléments à fournir par le projet. L’identification des tâches, l’évaluation et la planification sont donnent en effet des activités qui suivent mais à mon avis ne font pas partie du développement du WBS.
Voici quelques bons trucs qui m’ont servi bien dans le développement du WBS
- Concentrez-vous le quoi pas le comment. ”Qu’essayons-nous de faire, pas comment ?”
- Le WBS est une activité d’équipe, il devrait impliquer les parties prenantes du projet, pas seulement le chef de projet.
Donnez l’occasion à l’équipe de « remuer ses méninges » (brainstorm) en utilisant des post-it pour qu’ils puissent travailler tant de haut en bas que de bas en haut. Cela permettra de prendre en compte de multiples styles de travail. Ceux qui aiment commencer par la vue d’ensemble et ceux qui aiment les détails peuvent être satisfaits de cette réflexion en commun d’une façon qui les met à l’aise.- “Les mauvaises idées” devraient être encouragées pendant le remue-méninge et prises en compte lors de regroupements de livrables plus tard. L’avantage d’identifier un livrable qui est en dehors du périmètre projet est que cela peut être parqué sur une feuille séparée et documenté plus tard en tant que tel.
- Assurez-vous de documenter les suppositions faites par l’équipe et d’utiliser ensuite ces suppositions comme une entrée potentielle dans l’identification des risques.
- Ne vous contraignez pas à essayer de fournir les éléments dans l’ordre, cela viendra plus tard.
- Assurez-vous que l’équipe documente les livrables internes et externes. Chez IBM nous utilisions le terme « produit de travail » pour des livrables internes pour les distinguer des livrables qui entrent dans un énoncé des travaux (statement of work).
- Capturez les deux types de livrables. Beaucoup d’équipes oublient souvent qu’une une charte de projet et un plan projet sont en réalité des livrables qui devraient apparaître dans le WBS.
- Utilisez le développement du WBS comme une opportunité de construction d’équipe en rassemblant les membres du projet et en accélérant les étapes de développement d’équipe.
- Rappelez-vous la règle de 80 heures par lot de travail. À un bas niveau dans le WBS, on trouve les lots de travail. Ces lots de travail sont des livrables composés de tâches dont la somme devrait atteindre environ 80 heures d’effort.
Les bénéfices et utilisations du WBS sont multiples.
En identifiant la portée totale du projet par une décomposition par livrables, le WBS aide l’équipe de projet à réaliser les choses suivantes :
Comprendre ce qui est « à l’intérieur » et ce qui est « à l’extérieur » du périmètre du projet. Ce qui n’est pas listé, est en dehors. Ce processus peut permettre l’équipe de projet de documenter qu’un livrable donné est à l’extérieur du périmètre.- Envisagez les secteurs potentiels de risque, en vous servant des suppositions documentées.
- Construisez une fondation pour développer une référence de base solide de projet et chaque lot de travail peut être utilisé pour identifier des tâches principales selon règle des 80 heures.
- Communiquez avec des parties prenantes sur les besoins potentiels qui pourraient être demandés en croisant exigences et livrables.
- Établissez une responsabilité claire pour les lots de travail et assignez des propriétaires/champions.
Il y a beaucoup d’autres trucs et bénéfices pour le WBS, tels que le système de codage qui peut être utilisé ou comment se servir du WBS pendant la phase d’exécution et dans le processus de contrôle. Même si chacun de ceux-ci est une considération importante, mon focus pour ce billet a été en utilisation du WBS comme un robuste point d’ancrage pour l’équipe pendant le processus de planification.
Je conclurai en soulignant qu’un bon WBS peut en effet être un facteur différenciant entre un projet réussi et un échec. Ceux qui ne sont pas familiers avec le WBS ou ne savent pas comment le créer doivent passer du temps à parcourir le PMBOK Guide et autres livres qui contiennent les appropriées.
La méthode Prince2 Réussir les certifications Fondamental et Praticien : 1er livre agréé par l’APM Group
La méthode Prince2
Réussir les certifications Fondamental et Praticien
Collection: InfoPro, Dunod 2013 – 328 pages – 175×250 mm
EAN13 : 9782100594436
EAN13 : 9782100594436
PRINCE (PRojects IN Controlled Environments) est une méthode structurée de gestion de projets basée sur des processus, des thèmes et des principes qui s’applique à tout type de projets, informatiques ou non.
Elle est simple et structurante et permet aux entreprises qui la mettent en œuvre d’optimiser leur organisation en définissant des dérivabilités claires, de se focaliser sur ce qu’elles cherchent à produire et pas seulement sur les activités, et de pouvoir assurer un contrôle de haut niveau sur de multiples projets.
Elle fournit également un excellent outil de contrôle sur les projets développés avec des méthodes agiles en informatique. L’une des des dernières et plus retentissantes preuves de l’efficacité de la méthode fut son utilisation pour gérer les Jeux Olympiques de Londres.
Cet ouvrage vous permettra de comprendre et de maîtriser les concepts de PRINCE2®. Il comporte en outre des QCM d’entraînement aux examens pour préparer les deux certifications PRINCE2® : l’examen « Fondamental » (Foundation) et l’examen « Praticien » (Practitioner).
Cet ouvrage a été évalué et a obtenu une licence de l’APM Group, organisme qui accrédite des formations et gère des programmes de certifications dont PRINCE2®. ll a également le soutien de l’APMG-France qui promeut les bonnes pratiques en France.
Sommaire Gérer un projet selon PRINCE2. Qu’est-ce que PRINCE2? Pourquoi une méthode? Que propose PRINCE2? Les principes PRINCE2. Le projet PRINCE2. Avant le projet. En cours de projet. La fin du projet. L’adaptation du projet. Passer sa certification PRINCE2. Questionnaire pour la certification Fondamental. Questionnaire pour la certification Praticien. Annexes. Formulaires de produits de management. Relations de PRINCE2 avec d’autres référentiels méthodologiques. Méthodes de planification. Introduction aux techniques d’estimation. Quelques techniques de base. Glossaire.
Biographie des auteurs
Christian Descheemaekere – Ingénieur de formation. Après 30 ans de gestion de projets dans des environnements divers, et avec des responsabilités dans de grands groupes informatiques, il est aujourd’hui consultant et formateur en gestion de projets chez Mentor’s. Certifié formateur PRINCE 2®
Publics
Chefs de projet (informatique et autres) désirant découvrir PRINCE 2 et ceux désirant passer l’une ou l’autre des certifications (forte croissance du nombre de certifiés).
manager les bénéfices : «Managing Benefits»
Managing Benefits
http://www.apmg-international.com/home/Qualifications/ManagingBenefitsQuals.aspx
« Managing Benefits » est le dernier guide de conseils de APMG-INTERNATIONAL. Le but est de fournir aux managers et praticiens de multiples disciplines, travaillant dans une variété d’organisations, des conseils généralement applicables englobant des principes, des pratiques et des techniques de management des bénéfices.
« Managing Benefits » fournit:
- Une vue d’ensemble de la gestion des bénéfices. Ce que c’est, la raison de le faire, et quelques idées communes mais fausses qui peuvent limiter son efficacité dans la pratique.
- Les descriptions des sept principes sur lesquels des approches réussies de management des bénéfices sont construites et des exemples de comment elles peuvent être appliquées en pratique.
- Des conseils sur la façon d’appliquer le management des bénéfices au niveau d’un portefeuille de projets, aussi bien qu’à un projet individuel ou au niveau d’un programme.
- Les détails des cinq pratiques du Cycle de management des bénéfices et des exemples concrets de comment elles peuvent être été appliquées.
- Des conseils sur la façon de commencer dans l’implémentation de pratiques de management des bénéfices efficaces et de continuer à progresser.
Lisez/téléchargez le Managing Benefits Certification Leaflet.
Il y a un facteur primordial à la base de la décision de produire le guide. Les bénéfices ne sont pas simplement un aspect du management de projet et de programme (PPM), ils sont plutôt la raison d’investir des fonds des contribuables et actionnaires dans les initiatives de changement.
Ce nouveau guide a été soigneusement conçu en complément aux meilleures pratiques de management de Portefeuille, Programme et Projet (comme PRINCE2 ®, MSP ®, P3O ® et MoP™). Il consolide des conseils existants sur le management des bénéfices en un seul endroit, tout en couvrant les pratiques et les techniques spécifiques visant à optimiser la réalisation des bénéfices.
Pourquoi ?
Les raisons pour lesquelles des organisations et gouvernements investissent dans des projets et des programmes sont de réaliser des bénéfices en terme de :
- Accroissement du revenu;
- Économies par une plus grande efficacité;
- Livraison d’une contribution tangible à une priorité d’affaires ou objectif stratégique;
- Réponse à une disposition réglementaire ou légale ou pour maintenir le business.
Pourtant, les rapports d’organismes professionnels, d’agences d’audit et la recherche universitaire montrent que les organisations dans le public, privé et les secteurs tertiaires continuent à avoir du mal à démontrer un retour sur leurs investissements dans le changement.
La signification de ceci est encore plus grande dans un climat économique volatil où l’échec à optimiser la réalisation des bénéfices peut fort bien mettre des initiatives futures en danger car les investisseurs perdent leur confiance en la capacité de l’organisation à manager le changement.
Pour qui ?
Le guide est pertinent pour tous les secteurs et types de projet ou programme, ce que le guide appelle des « initiatives de changement ».
L’audience cible englobe donc tous ceux qui ont un rôle dans s’assurer que l’utilisation des fonds des contribuables et/ou actionnaire est optimisée en maximisant les bénéfices réalisés par les initiatives de changement. Ce groupe multidisciplinaire inclut:
- Les leaders de changement (par exemple les propriétaires responsables et les directeurs de changement)
- Les initiateurs de changement (des planificateurs stratégiques par exemple et leaders de politiques)
- Les experts et estimateurs de changement (des développeurs de cas d’affaire / business case par exemple et auditeurs de projets)
- Les réalisateurs/activateurs du changement (par exemple, les managers de Portefeuilles, Programmes et Projets)
- Les équipes de support au changement (par exemple, le personnel des bureaux de portefeuille, programme et projet)
using MS Project for Agile projects
Agile project management methodologies (such as Scrum, Extreme Programming and others) are based on process-centric and iterative development rather than a traditional waterfall approach. Some of the key characteristics of an agile project include a backlog, burn-down charts, frequent communication, and short-cycle delivery of project outputs that don’t typically lend themselves to traditional MS Project scheduling techniques. But in this informative webinar, we’ll show you techniques and tips on how to use MS Project to effectively manage projects in the new frontier of Agile Project Management!
This session is presented by Matt Davis, PMP, MCITP, President of the Microsoft Project Users Group (MPUG) Boston Chapter.
Webinar: Get started with Project
Some people start up Microsoft Project with the greatest intentions. They add a few tasks, and then freeze–unsure of what to do next. In this webinar, we’ll show you how to get past that. We’ll demo the basics so that you can get started with more confidence and less stress.
l’Audit Projet, synthèse Synertal par Vincent Iacolare
Vincent Iacolare est Ingénieur INSA de formation et immergé dans le monde de l’innovation et des technologies depuis 1986. Vincent a pratiqué le management de projet et de programme dans divers environnements (aéronautique, défense, énergie, automobile, ingénierie, système d’information, etc.) en tant que manager de projet, assistant à maîtrise d’ouvrage et maîtrise d’œuvre, ingénieur assurance qualité projet et auditeur.
Depuis 2006, il pilote la société Synertal comme un bureau de projets où tout sujet, action, opération interne comme externe est conduit comme un projet. Écrivain militant sur l’entreprise (cf. www.talentrepreneur.fr), il est l’auteur de nombreux articles et ouvrages publiés chez Afnor Éditions. Pour en savoir plus : http://talentrepreneur.fr/content/vincent-iacolare
Le 26 mars 2013, l’Afitep a organisé une soirée Management de Projet sur « L’audit contribue-t-il à la performance d’un projet ? ». Un thème très attendu tant l’assurance qualité projet et l’audit projet sont si peu appréciés des acteurs du projet. De quoi convertir les plus perplexes, pour apporter toujours plus de valeur ajoutée au projet ! En voici une brève synthèse.
L’audit est un « processus méthodique, indépendant et documenté permettant d’obtenir des preuves d’audit et de les évaluer de manière objective pour déterminer dans quelle mesure les critères d’audit sont satisfaits » (ISO 1901).
L’audit projet entre dans les dispositifs d’assurance qualité projet (donner la confiance a priori au client) et reste avant tout un outil de progrès. Il permet de s’assurer que les activités du projet sont conformes à la politique interne, aux processus et aux procédures de l’organisation du projet. Il contribue au dispositif de surveillance de la conformité aux politiques de normes, procédures et modèles de management de projet définis sur le projet.
Les audits de projet peuvent être conduits en tant que tels ou associés à d’autres actions de mesure et surveillance (revue, comité, …). Le format de l’audit (périmètre, objectifs, …) sont clairement définis avant que l’audit ne soit conduit (dans le plan de management du projet et/ou les plans spécifiques (plan d’assurance qualité, plan de gestion des risques, plan d’approvisionnement, …).
Ils sont planifiés ou déclenchés sur dysfonctionnement ou décision du commanditaire. Ils sont conduits par des membres de l’équipe projet (indépendants de l’activité auditée) ou non, interne ou externe à l’entité.
Les étapes de l’audit projet sont similaires à celles de tout audit à valeur ajoutée. Une importance encore plus particulière est donné à l’étape d’expression de besoins.
Plusieurs objectifs possibles :
- identifier toutes les bonnes pratiques mises en œuvre (et alimenter la base des leçons apprises),
- identifier les lacunes et imperfections,
- benchmarker par rapport aux meilleures pratiques mises en œuvre dans dans des projets similaires dans ou hors de l’entité,
- proposer des améliorations pour la mise en œuvre des processus et augmenter ainsi la productivité de l’équipe projet
Différentes natures d’audit projet :
- Audit de conformité et/ou de maturité et/ou de progrès,
- Audit de processus mis en œuvre sur le projet, Audit de procédure, Audit de système (fournisseur, sous-traitant), Audit technique (Audit de configuration, audit de caractéristiques technique produit)
Plus précisément, voici quelques exemples d’audits possibles : Audit et revue de la configuration, Audit qualité, Audit de mesure et analyse de la performance du projet, Audit du processus d’amélioration continue (réclamation, prévention, …) , Audit d’assurance qualité projet, Audit de contrôle qualité et Inspection, Audit des stratégies de réponse aux risques du projet , Audits des approvisionnements, Audit fournisseurs et sous-traitants , Audit de contenu (spécifications, livrables) du projet , Audits finaux de projets
Et pour apporter encore plus de valeur ajoutée et faire un audit projet performant :
- Être encore plus rapide
Gagner du temps, gérer ses priorités, être organisé, avoir le bon auditeur au bon endroit au bon moment, Adapter le processus classique d’audit (renforcer l’étape de revue préalable documentaire pour alléger l’audit terrain, mobiliser
- Être innovant et force de proposition dans les conclusions et restitutions de l’audit
Pour y parvenir voici quelques techniques : disposer d’une base de connaissances, d’une base d’experts, et d’une boîte à outils et pratiquer la fertilisation croisée et la veille
Pour en savoir plus : Formation Afnor « Assurance qualité projet », Ouvrage Afnor Editions « Solutions pour… Pratiquer l’audit à valeur ajoutée », Classeur à feuillet mobile Afnor Editions « L’audit projet ».
Tous les ouvrages de V. Iacolare sur http://talentrepreneur.fr/content/vincent-iacolare
définition des statuts de projet Rouge/Orange/Vert
RAG (Red, Amber, Green) Status Definition
http://www.leadershipthoughts.com/blog/rag-status-definition/ par Tristan Wember
Les états d’avancement de projet utilisent souvent la définition de statut ROUGE/ORANGE/VERT comme une indication visuelle de performance de projet.
Cependant, l’efficacité de cet outil repose complètement sur l’intégrité du chef de projet et l’exactitude de la couleur du statut assignée. Une couleur inopportune peut mener à éviter d’affronter un problème et en supporter l’échec en fin de projet. Son but est de démontrer du progrès et de préciser quand l’intervention du comité de projet est nécessaire.
Définition des couleurs de statut
Le contrôle et suivi du projet (voir The Highlight Report) est à propos de mesurer l’avancement, prendre des actions correctives et garder les parties prenantes informées.
Donc, le statut de ROUGE /ORANGE/VERT ne devrait pas être utilisé pour cacher des problèmes. C’est plutôt une façon de rechercher du support et des conseils du sponsor et des parties prenantes seniors. Utilisez une définition de statut ROUGE/ORANGE/VERT commune pour communiquer vers vos parties prenantes.
|
Statut |
Définition |
Action |
| ROUGE | Il y a des problèmes significatifs sur le projet.Le projet exige que l’action corrective pour atteindre les objectifs fonctionnels. Le problème ne peut pas être traité uniquement par le chef de projet ou l’équipe projet.Un ou plusieurs aspects de la viabilité du projet (coût, délais, contenu) excèdent les tolérances agréées avec le comité de projet. | Le sujet devrait être immédiatement remonté au sponsor de projet et au comité de projet. |
| ORANGE | Un problème a un effet négatif sur la performance de projet, mais peut être traité par le chef de projet ou l’équipe de livraison de projet.L’action est entreprise pour résoudre le problème ou une décision prise pour surveiller la situation.Un ou plusieurs aspects de la viabilité du projet (coût, délais, contenu) sont à risque. Cependant, la déviation par rapport au plan reste dans les tolérances assignées au chef de projet. | Le comité de projet devrait être notifié utilisant un État d’avancement ou un briefing déjà prévu avec le sponsor. |
| VERT | Le projet progresse comme prévu.Tous les aspects de la viabilité du projet (coût, délais, contenu) sont dans la zone de tolérance. | Aucune action nécessaire. |
Un rapport d’avancement efficace ROUGE/ORANGE/VERT
Utilisez la définition de statut de ROUGE /ORANGE/VERT avec discernement et faites un rapport seulement sur quelques domaines comme le progrès général, la performance par rapport aux délais du projet, au budget et au contenu. Beaucoup de chefs de projet ou sponsors cherchent à mettre trop de détails dans un rapport d’avancement et manquent de voir et traiter des problèmes parce qu’ils ne peuvent pas distinguer les arbres de la forêt.
Qui plus est, faites un rapport sur la tendance de progression. Comparez le statut actuel avec une période précédente. Montrez par exemple le statut ROUGE /ORANGE/VERT tant pour cette semaine que la semaine précédente pour mettre en évidence l’évolution.
à votre tour…
Utilisez-vous une définition de statut ROUGE/ORANGE/VERT ? Combien de fois préparez-vous des états d’avancement ?
Campana & Schott a été nommé finaliste pour le « Microsoft Partner of the Year Award 2013
Notre partenaire concoure dans les catégories « gestion de projet » et » gestion de portefeuille ». Cet « Oscar » est attribué aux partenaires proposant des solutions pour Microsoft Project Server. Plus de 3000 entreprises de 100 pays différents avaient postulés pour les 44 prix à obtenir ; Campana & Schott, pour sa première participation, atteint directement la place de finaliste pour avoir présenté CS Connect.
« Les lauréats du “Partner of the Year Award” représentent les meilleures entreprises de notre écosystème » a indiqué Jon Roskill (corporate vice president, Worldwide Partner Group, Microsoft).
La solution présentée par Campana & Schott s’adresse aux entreprises focalisées sur la recherche, l’engineering et le développement. Elle permet d’obtenir une vision globale du cycle de vie complet d’un produit – de la sélection des idées d’innovation jusqu’à la gestion des métadonnées, des documents, des tâches, des plannings et des coûts – avec un seul outil en combinant les données de MS Project Server, MS SharePoint Server et l’ERP SAP. CS Connect est certifié par Microsoft et par SAP pour l’intégration de Microsoft Project / SharePoint Server et désormais Project Online avec SAP.
« Cette nomination vient confirmer le succès de notre choix d’allier le conseil en management de projet et en technologie afin de développer nos propres produits logiciels permettant de proposer des solutions complètes pour répondre aux besoins complexes de nos clients. » a déclaré Eric Schott, CEO de Campana & Schott.
rencontrez les créateurs de MS Project 1.0
Meet the project 1.0 creators
http://blogs.msdn.com/b/project/archive/2012/06/22/meet-the-project-1-0-creators.aspx
Il y a quelque temps l’équipe de développement de MS Project avait l’honneur de rencontrer ses géniteurs si l’on peut dire : Brian MacDonald et Jeff Lill. Ils sont les créateurs originaux de la première version de Project pour Windows qui est sortie en 1990.
Ils ont commencé comme deux enfants qui ont grandi à seulement quelques kilomètres du campus Microsoft. Au lycée, ils ont pensé qu’il était cool de programmer de petits LED à s’allumer et s’éteindre. Cette fascination a inspiré leur avenir dans le développement logiciel.
Ils ont passé un certain temps à étudier à l’Université de Washington et pendant qu’ils y étaient ont construit une application de vérificateur d’orthographe, Corrector. Malheureusement c’était le troisième vérificateur d’orthographe sur le marché et même si InfoWorld l’avait évalué comme le meilleur de l’industrie, ils en ont vendu seulement 24 copies. Brian doit sa bonne orthographe actuelle à la nécessité de saisir manuellement le dictionnaire tout entier. Jeff a même fait certains stages chez Microsoft pour financer leur société.
Après l’application de vérificateur d’orthographe, ils ont commencé à travailler sur un tableur pour Mac appelés « Crunch ». Peu de temps après cela, Microsoft a sorti Excel et selon les mots de Brian « vraiment crunché Crunch ». À cette époque, ils avaient beaucoup de connexions chez Microsoft provenant des stages de Jeff et de la femme de Brian qui y travaillait. Ils étaient à une fête avec Bill Gates et il a mentionné qu’ils devraient arrêter de rivaliser et commencer à bosser ensemble. Microsoft essayait de recruter des développeurs pour développer l’interface graphique (GUI) des applications pour cette nouvelle plate-forme appelée Windows. Ils avaient déjà un tableur et un traitement de texte, mais cherchaient des développeurs pour créer une application de base de données (qui deviendrait Access) et une application de management de projet. Brian et Jeff ont choisi cette dernière.
Alors que Brian et Jeff avaient beaucoup de passion pour le domaine du logiciel, ils n’avaient pas beaucoup d’expertise de management de projet. Comme l’a dit Jeff par contre, ils étaient assez arrogants pour savoir qu’ils pourraient le faire. Alors, ils s’y sont plongés, ont observé les concurrents, fait une série d’entretiens clients incluant avec une autre société locale, Boeing, lu des livres de management de projet et suivi des conférences. C’était en réalité pendant qu’ils étaient sur une visite de site chez Boeing qu’une ampoule s’est allumée et qu’ils en sont venus à la décision qu’ils voulaient construire une boîte à outils qui aurait un si large attrait que quiconque pourrait l’utiliser pour le management de projet. À l’époque la plupart des applications de gestion de projet avaient été construites par des consultants et le logiciel soutenait la méthodologie que vendait le consultant. Mais la plupart des sociétés avaient déjà une méthodologie en place et voulaient seulement un logiciel qui la supporte. Cette décision s’est avérée être centrale et une chose que Microsoft croit toujours fortement être correct de nos jours. Dans les versions actuelles de Project, vous verrez que vous pouvez manager les projets comment vous voulez les gérer.
Comment ressentez-vous le fait qu’aujourd’hui les gens utilisent toujours l’outil que vous avez construit pour d’énormes projets cumulant des milliards de dollars ?
C’est super ! Nous avions toujours espéré que ce serait le cas. – Jeff
Y-a-t-il des réactions des gens qui vous étonnent ?
À peu près quand la deuxième version de Projet sortait, la popularité de Windows a à juste exploser et avec cela celle de tout logiciel qui fonctionnait sous Windows. Nous avions initialement vu notre clientèle comme les personnes qui avaient « Chef de projet » dans leur titre, mais avons constaté que le produit avait un attrait beaucoup plus large. Les gens l’utilisaient pour créer des diagrammes de planning/Gantt pour les aider à montrer à leur management/équipe qu’ils savaient où ils allaient et maîtrisaient les choses. – Brian
C’était très passionnant pour eux et cela a aidé le produit à décoller vraiment. Ils attribuent aussi ce succès à leur objectif initial d’être une boîte à outils au lieu d’une solution spécifique. Ceci est pourquoi les fonctionnalités comme la capacité de renommer des colonnes étaient disponibles depuis la sortie originale.
Quels genres d’améliorations avait la deuxième version de Projet sur la première ?
L’aperçu avant impression, le support pour des macros et les améliorations à l’algorithme de nivellement étaient les principales.
Oui, le nivellement était dans la v1. Selon Jeff – « Toutes les solutions logicielles l’avait et toutes avaient du mal à le faire marcher comment les gens s’y attendaient ». Nous essayons toujours de rendre cela plus facile aujourd’hui en ajoutant des fonctionnalités comme l’accentuation des changements dans le Project 2007 et le Planificateur d’Équipe dans Project 2010.
Que pensez-vous de la version actuelle de Projet ?
Elle est superbe. Beaucoup de ressemblance avec l’interface utilisateur complète mais cela semble certainement plus moderne (ils étaient heureux d’entendre que nous avons maintenant plus que les 16 couleurs). Pour la vue de chronologie, c’était ce que nous essayions de réaliser avec le diagramme de Gantt (partager l’échéancier avec les parties prenantes) mais avec maintenant une attractivité encore plus forte. – Brian
Après Project, Brian a continué en créant Outlook qui est à l’origine parti dans le but d’être une application de gestion de tâche. C’était seulement pendant le développement et après beaucoup de débats qu’ils ont décidé d’y ajouter le support de courrier électronique. Nous pensons qu’ils ont pris la bonne décision. Jeff a travaillé sur Project un peu plus longtemps et a ensuite continué pour faire Team Manager. Aujourd’hui ils travaillent tous les deux dans l’organisation Bing.
Quelques faits amusants :
· Il n’y a pas de MS Project 2.0 parce que quelqu’un d’autre avait déposé les droits d’auteur sur Project 2.0
· Bill Gates a essayé de les convaincre de récrire Project en BASIC et ils ont dit non.
· le dernier bogue fixé pour Project 1.0 pour Windows était autour du support de la vue du Diagramme de Gantt avec le formulaire de tâche.
Bref, je voudrais remercier Brian et Jeff d’avoir créé ce super produit que tant d’entre nous utilisent chaque jour et sur lequel ils comptent pour accomplir une vaste gamme de projets.
5 étapes pour prioriser vos priorités
5 Steps to Prioritize Your Priorities
http://www.johnmaxwell.com/blog/5-steps-to-prioritize-your-priorities par The John Maxwell Company.
Priorités : Nous en avons tous, mais il est difficile de déterminer qui devrait passer en premier. Pendant de nombreuses d’années, John Maxwell a utilisé deux lignes directrices pour mesurer son activité et déterminer ses priorités.
L’une d’elles est le Principe ce Pareto. Ce principe, aussi connu comme la règle du 80-20, déclare que 20% de vos activités représenteront 80% de vos résultats. Donc, si vous avez une liste de 10 choses à faire, 2 de celles-ci vaudront 5 ou 10 fois plus que les 8 autres choses réunies.
Ce principe se connecte fortement à ce que The John Maxwell Company appelle la « Règle de 5 ». Inspiré de la Règle de 5 de John Maxwell, notre équipe a créé sa propre Règle de 5 – Une liste de choses nous faisons CHAQUE jour – et vous encourageons à faire le même.
« Il n’y a jamais assez de temps pour tout faire, mais il y a toujours assez de temps pour faire la chose la plus importante. »
Si vous créez une Règle de 5 pour votre organisation ou vous-même, les astuces suivantes vous aideront à commencer.
1. Écrivez noir sur blanc votre objectif principal. Ceci sera votre ligne directrice comme vous créez votre Règle de 5. Votre Règle de 5, ce sont les étapes que vous devez suivre pour atteindre votre but.
2. Construisez votre liste « importante ». Ceci peut être fait de différentes façons : a: Faites une liste des tâches pour votre journée. Incluez tout qui doit être fait ce jour, ainsi que des choses que vous avez pour but de compléter au fil du temps. Ou b: Notez une liste de chaque chose que vous faites pour avoir du succès. Ceci peut aller de lire et écrire à rencontrer des membres de l’équipe et construire des relations.
3. Classez les choses par ordre de priorité. Si des articles divers sont semblables, vous pouvez les catégoriser pour vous aider dans le processus de priorisation.
4. Mettez en évidence les 20 premiers pour cent de vos priorités et faites une liste mémorisable de 5 choses qui vous permette d’allouer la majorité de votre temps à ces choses.
5. Imprimez votre Règle de 5 et accrochez-la où on la voit fréquemment. La répétition est la clé.
Après avoir fini ces 5 étapes, vivez avec assurance votre règle de 5 chaque jour … même les week-ends et même quand vous êtes occupé !
Si vous avez toujours des difficultés à créer votre Règle de 5, chercher l’apport de ceux qui vous connaissent le mieux ainsi que votre rôle. Asseyez-vous avec un superviseur et demandez-lui de parler de votre Règle de 5. Quoi qu’il advienne, la clé est que les articles sur votre Règle de 5 doivent être faits chaque jour et doivent être assez simples à réaliser toutes les 24 heures.
« Que vous ayez 20 ans ou 50 ans, vous et moi pour être efficaces devons vraiment donner le meilleur que nous pouvons chaque jour : l’utilisation de notre temps, dons et ressources pour faire une différence. »
Leaders, qu’avez-vous découvert dans le processus de création de votre propre Règle de 5 ?
Nous aimerions vous entendre! Partagez avec nous dans les commentaires ci-dessous ou bien sur Facebook ou Twitter en utilisant le Hashtag #Ruleof5.
DantotsuPM.com 