J’ai eu le privilège de participer à une formation délivrée par Guillaume Pertinant sur ce sujet. Guillaume a mis sa présentation à disposition de tous. Simple et claire, elle reprend les principales idées reçues sur le stress pour sensibiliser sur ce douloureux sujet.
Équipes multi générations et leur impact dans le management de projet
Même si toute généralisation est propice à des erreurs d’appréciation, se poser la question de comment utiliser au mieux des ressources de divers ages qui ont donc une tendance à utiliser divers modes de communication, à avoir des valeurs et un rapport à la hiérarchie significativement différents, ne peut que vous apporter un plus dans votre management d’équipe de projet.
Sur les news PMI, lisez l’article original en anglais: Multigenerational Teams and Their Impact in Project Management de Conrado Morlan, PMP, PgMP et Jamie B. Gelbtuch, MBA, PMP
Traduction personnelle.
Alors que les chefs de projet luttent tous les jours avec des budgets, des planning et des problèmes d’équipe, pour la première fois depuis des décennies un nouvel élément de diversité est adressé — le management d’équipes multi générations.
Bien que l’équipe multi générations existe depuis toujours, la performance de projet est affectée par des perceptions mal comprises de la conduite des membres de l’équipe. Le défi est de concilier des comportements de générations et des valeurs pour créer la synergie exigée pour le projet.
Des équipes de projet incluent maintenant des membres de quatre générations différentes. Des générations plus vieilles incluent Les Matures (nés avant la Deuxième Guerre mondiale) et les Enfants du baby-boom (qui ont grandi dans la prospérité de l’après Deuxième Guerre mondiale) . Des générations plus jeunes comme la génération X (né du milieu des années 1960 au début des années 1980) et la génération Y (les diplômés du nouveau millénaire).
Les générations, comme des cultures, sont semblables aux icebergs. Chacune a des actions et des comportements (« ce » qu’ils font) caractéristiques qui sont très visibles, bien qu’ils représentent seulement les 10% de l’iceberg que nous voyons au-dessus de la ligne de flottaison. Les croyances sous-jacentes des générations et les attitudes (« pourquoi » ils le font) sont en grande partie invisibles, semblables aux 90% de l’iceberg cachés sous l’eau.
Pour essayer de comprendre les motivations invisibles de ces comportements, les chefs de projet peuvent regarder beaucoup de dimensions qui varient selon les cultures. Les générations montrent des tendances différentes sur l’utilisation et la perception de:
Hiérarchie et Autorité
La fidélité et le respect sont un dénominateur commun pour « Matures » et la « Génération Y« . Le Mature est loyal envers les institutions et respecte l’autorité, tandis que le Génération Y est loyal envers les personnes et respecte les vétérans. Les baby-boomers sont les champions du travail d’équipe et de l’équité mais pensent que les règles peuvent être questionnées. Le Génération X, au contraire, n’aime pas le micro-management et pense que les règles sont dynamiques et définies par des individus plutôt que des institutions.
Temps personnel et Temps de Travail
Les enfants du baby-boom et les Matures donnent au travail une forte priorité. Cependant, les Matures ont tendance à apprécier des horaires flexibles tandis que les Enfants du baby-boom se préoccupent du nombre d’heures consacrées aux projets, indépendamment de la productivité. La Génération X est caractérisée par un désir de contrôler et de définir leur parcours professionnel, ambitions personnelles et leur lieu et temps de travail. Un besoin fort conduit la Génération Y vers la recherche de l’équilibre entre travail et vie personnelle et les avantages qui permettent une carrière gratifiante.
Moyens de Communication Préférés
Comme les Matures ont grandi dans un environnement avant les ordinateurs, ils ont développé des compétences relationnelles fortes et valorisent les communications en personne. Les enfants du baby-boom croient aussi que le temps en face à face est important, quoiqu’ils aiment le faire suivre par un écrit. Génération X et Génération Y accordent moins de valeur au temps en face à face. Le Génération X recherche la communication ouverte indépendamment de la hiérarchie et du statut, tandis que le Génération Y aime la communication n’importe quand, n’importe où, et recherche la confirmation positive de supérieurs.
En se basant sur ces tendances, les chefs de projet peuvent ajuster les manières traditionnelles dont ils choisissent et managent des équipes de projet en s’adressant aux membres de l’équipe sur la base des générations. Les suggestions pour surmonter une mentalité multi générations incluent :
- Comprendre. Chacun a raison — tout est affaire de perception. Les croyances et valeurs ne peuvent pas être facilement (voir pas du tout) changées, donc nous devons travailler avec les membres de l’équipe tels qu’ils sont, indépendamment de leur âge.
- Questionner. Une question simple comme « si vous étiez dans mes chaussures, comment traiteriez-vous cette situation ? » Donnera une énorme visibilité des motivations d’une autre génération.
- Démontrer son engagement. Garder un dialogue ouvert et continu montre un effort de bonne volonté de travailler avec plutôt que contre les différences.
Le succès suprême d’une équipe multi générations dépend de la capacité d’un chef de projet à mener et inspirer une équipe pour non seulement reconnaître, mais aussi concilier ces différences.
Avec une approche pro-active, l’équipe de projet sera capable de chercher des similitudes et de tirer parti de vues divergentes. En tant que chef de projet ou membre d’équipe de projet, comment faites-vous actuellement face à ce défi ?
I am becoming the sponsor of a project, what should I do?
In the literature on project management, the role of project sponsors seems to appear in the 70s. It is at this time that project management spread to all the industries and activities instead of being limited to big construction projects, military and the aeronautics. Certain companies then started to reorganize by project and it rapidly appeared that there were not enough business leaders to lead directly all projects. These leaders had to rely on more operational project managers while keeping a business sponsor’s role and remain the ultimate person responsible for the project.
Being a project manager as many readers of this blog, becoming the sponsor of a project is like crossing the mirror. The PM whom I am has very strong expectations (but nevertheless realistic) of his(her) sponsors. If I became a sponsor, which would or should be my first concerns?
Certainly first of all to define precisely my role and expectations of the PM, in the same way as he or she will have expectations of what I should bring to the project. It is thus necessary to establish mutual trust between us based on clearly established roles and responsibilities, regular communications, and common rules. Let us establish these jointly during a first working session.
Business Champion, legitimacy.
To perform successfully his role, the sponsor must be listened to and recognized by his peers in the business and by his management. It is therefore critical that I get in touch with all stakeholders of the project. I need to understand clearly their expectations of the project, their necessary level of involvement, and to listen to their points of view. It will be in particular useful at this time to obtain an access to their expert resources of the domain. And, also these discussions shall enable me to appreciate the problems to be addressed from the insiders’ view.
Direction and support in decision-making
Here is one of my sponsor’s key roles. It is a matter of giving a direction and management support to the project manager. It is thus imperative that I have an excellent and very clear overall view of the objectives of the project and that I am able to articulate and to communicate these simply and effectively. And this for all the stakeholders: the project manager and his team of course, but also the management of my company, including or maybe even in particular towards those who seem less impacted by the project but have a large influence in the company (not always high-ranking individuals).
Review and approval of plans and deliverables
Beyond the adequacy of the deliverables and project plans to the concrete objectives of the project, my sponsor’s role is to improve these project’s deliverables and to approve them formally. The best sponsors that I had as PM, had the capacity to see farther than the deliverables in themselves. They perceived early how these products would be welcomed according to the expectations of the many stakeholders. They anticipated the potential negative reactions to prevent these, often by modifications which may seem to be cosmetic but which made a huge difference. They were always one or two steps forward in their reflection with regard to my inevitably more operational focus.
Guaranty the availability of the assigned resources in due time (Including my own)
I shall be demanding and even inflexible on the provision in due time of the resources promised to the project team to succeed. How could I be strict on any drift of the project if the authorized means are not provided? The most difficult one will be probably my own availability to the project manager. It must be easy to obtain, immediate, and especially with a 100 % of my attention dedicated to the project on these occasions.
Remove the obstacles
In addition to supplying the necessary resources, I have the duty to unlock complex situations or crisis that the PM despite of all his/her efforts (because it is first of all his/her role to do so) would not know how to address. It does mean removing the responsibility from the PM’s shoulders but rather supplying the required support when necessary.
Establish and decide on the priorities
What should we do? Delay the project production date by a few days or to exceed the budget? The PM will supply me the arguments in favor and against these two alternatives, and possibly his/her recommendation. The decision will be on me and I shall have to take into account all of the following: the objectives and the imperatives of the business, the operational and commercial impacts, the stakeholders… This type of decision cannot be put off and, very often, no decision is worse than making an error which we will correct later.
Examine regularly the progress
A combination of formal and informal sessions seems to me an efficient approach. Formal project committees and the other gates or milestones reviews are necessary but often insufficient. Indeed, reading a report or listening to a well prepared presentation speech will not allow me to understand what’s really happening. It is necessary to read between lines, to hear the unsaid, the intangible, to appreciate the difficulties of the PM and to have a real human relationship. In my past projects, brief (30 minutes) and regular (weekly) sessions appeared to me to be the most effective.
Promote frank and open communications (put down the masks!)
To get the vital info, including the bad news that are difficult to hear, I need on my side to be frank and open with the PM. To communicate without taboo or hidden agenda is a must do. Except information that could place the company at risk such as the legal issues (some financial information for example, or reorganizations and mergers/acquisitions), everything can be explained with a little bit of intelligence and trust.
Provide standards of performance
To be opened and approachable does not mean being permissive. My best sponsors were inflexible with me and my team. I had very clearly their support and knew perfectly what they expected from me. We had high standards of quality and performance and these were mutually shared.
Develop an organization which learns from its mistakes and successes
Finally, as the sponsor of an important project of the company and thus member of its senior management, I owe to develop the skills and the know-how of the resources which are under my leadership and to make sure that The lessons learned will benefit future projects.
meet me in Milano next month for the PMI Global Congress—EMEA 2010
The PMI Global Congress—EMEA 2010 will take place in Milan on May 10-12. And… I’ll be facilitating a session on Leadership in Project Management.
This is the leading annual opportunity for Project Managers to come together for educational sessions and international networking. It is a focal activity for project management across Europe, Middle East and Africa.
Innovate your usual approach to managing project constraints, and achieve desired outcomes. This three-day professional development event hosted by PMI provides a focused environment for you to rethink the norm, connect with your peers, and reaffirm your professional commitment by building your knowledge and skills. A PMI global congress provides a forum in which practitioners and professionals can network; discuss trends in project, program and portfolio management; and earn professional development units (PDUs) toward maintaining PMI professional credentials.
The PMI Global Congress 2010—EMEA includes numerous sessions on topics such as project management trends, the use of new media and social networking tools, using methodologies such as agile to complement general project management practices, and skills needed to manage risk in the new economy.
Keynote Speaker John Kao—A “Serial Innovator”
Join « the Innovation Guru » for an insightful (and musical) talk on the intersecting subjects of corporate innovation and transformation, design, and the future of business.
Registration Discounts
– Early Bird fees – Save up to €165 when you register for congress by 30 April 2010
– Group Discounts- Your company has several employees working with projects? Get together a group of your colleagues and save 10% to 20% with our group discount programme. All you have to do is email (claudia.fortes@pmi.org) or fax (+32 2 743 1550) the first page of the PDF registration form (one registration form per colleague) that is available online.
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.
Examens Papiers PMI en France
Suite à une demande par courrier électronique d’un lecteur de ce blog, je vous rappelle que 
PMI France-Sud organise chaque année plusieurs sessions papiers d’examens de PMI (PMP et CAPM).
Les dates, lieux et modalités d’inscriptions sont consultables sur le site PMI France-Sud.
Et, plus spécifiquement sur cette page
je deviens le sponsor d’un projet, que faire?
Dans la littérature sur le management de projet, le rôle de sponsor de projet semble apparaître dans les années 70s. C’est dans cette période que le management de projet s’est développé dans toutes les industries et activités au lieu d’être cantonné aux grands projets de construction, du militaire et de l’aéronautique. Certaines entreprises se sont alors organisées par projet et il est apparu qu’il n’y avait plus assez de leaders business pour conduire directement tous les projets. Ces leaders devaient s’appuyer sur des projet managers plus opérationnels tout en conservant le rôle de sponsors business et responsables ultimes du projet.
Étant un chef de projet comme beaucoup des lecteurs de ce blog, devenir sponsor de projet revient à traverser le miroir. Le PM que je suis a des attentes très fortes (mais tout de même lucides) de ses sponsors. Si je devenais sponsor à mon tour, quelles seraient mes premières préoccupations ?
Certainement en premier lieu de bien définir mon rôle et mes attentes envers le PM, au même titre qu’il ou elle aura des attentes de ce que je peux lui apporter. Il est donc nécessaire d’établir une relation de confiance entre nous basée sur des rôles et responsabilités clairement établis, de communications régulières, des règles de vie. Établissons-les en communs lors d’une première session de travail.
-
Champion métier/business, légitimité.
Afin de remplir pleinement sa fonction, le sponsor doit être écouté et reconnu de ses pairs dans le business et de son management. Il est donc critique que je prenne contact avec les parties prenantes du projet: les « stakeholders ». J’ai besoin de bien cerner leurs attentes du projet, leur niveau d’implication nécessaire, et d’écouter leurs points de vue. Il sera en particulier utile d’obtenir un accès à leurs ressources expertes du domaine pour lequel œuvre le projet et de bien comprendre les tenants et les aboutissants de la problématique à adresser.
Direction et soutien décisionnel
Voici l’un de mes rôles clés de sponsor. Il s’agit de donner une direction et un support managérial au chef de projet. Il est donc impératif que j’ai une excellente vue d’ensemble très claire des objectifs du projet et que je sois capable de les articuler et de les communiquer simplement et efficacement. Et à toutes les parties prenantes: le chef de projet et son équipe bien sûr, mais aussi le management de mon entreprise, y compris ou peut-être même en particulier vers ceux qui semblent moins impactés mais ont une grande influence dans la société (pas toujours les plus hauts placés).
Revue et approbation des plans et livrables
Au-delà de l’adéquation des livrables et plans de projet aux objectifs concrets du projet que nous avons établis ensemble, mon rôle de sponsor est d’améliorer ces livrables et de les approuver formellement. Les meilleurs sponsors que j’ai eu en tant que PM, avaient la capacité de voir plus loin que les livrables en eux-mêmes. Ils percevaient à l’avance comment ces produits seraient accueillis selon les attentes des divers « stakeholders ». Ils anticipaient les éventuelles réactions négatives pour les prévenir, souvent par des modifications cosmétiques en apparence mais qui faisaient la différence. Ils avaient toujours un ou deux coups d’avance dans leur réflexion par rapport à mon focus nécessairement plus opérationnel.
Assurer la disponibilité des ressources allouées (y compris la mienne)
Je me montrerai exigent, voire intransigeant sur la mise à disposition dans les temps des ressources promises à l’équipe projet pour réussir. Comment être sévère sur toute dérive du projet si les moyens agréés ne sont pas fournis? Le plus difficile sera probablement ma propre disponibilité envers le chef de projet. Elle doit être facile à obtenir, sans délais, et surtout 100% de mon attention doit être dédiée au projet dans ces occasions de rencontre.
Éliminer les obstacles
En sus de fournir les ressources nécessaires, j’ai le devoir d’intervenir efficacement pour débloquer les situations complexes ou les crises que le PM malgré tous ses efforts (car c’est en premier lieu son rôle) ne saurait résoudre. Il ne s’agit pas de déresponsabiliser le PM mais au contraire de lui fournir le support dont il a besoin quand cela est nécessaire.
Établir et trancher sur les priorités
Que faire? Décaler une mise en production de quelques jours ou dépasser le budget? Le PM saura me fournir les arguments pour et contre de ces deux alternatives, et éventuellement sa recommandation. La décision m’en reviendra et je devrai prendre en compte les objectifs et impératifs business, les impacts opérationnels et commerciaux, les « stakeholders »… Ce type de décision ne saurait être remis et, souvent, pas de décision est pire que de faire une erreur que l’on corrigera plus tard.
Examiner régulièrement l’état d’avancement
Une combinaison de réunions formelles et informelles me semble une bonne base d’efficacité. Le coté formel des comités de projet et autres revues de jalons et de documents est nécessaire mais souvent insuffisant. En effet, ce n’est pas en lisant un rapport ou en écoutant un laïus de présentation bien rodé que l’on perçoit ce qui se passe réellement. Il faut lire entre les lignes, comprendre les non-dits, les intangibles, apprécier les difficultés du PM et avoir une vraie relation humaine. Dans mes projets passés, de brèves (30 minutes) sessions fréquentes (hebdomadaires) et régulières m’ont paru être les plus efficaces.
Promouvoir une communication franche et ouverte (bas les masques!)
Pour avoir l’info vitale, y compris les mauvaises nouvelles difficiles à entendre, il faut que de mon coté je sois franc et ouvert avec le PM. Communiquer sans tabou ni agenda caché est un pré-requis. Hormis certaines informations de nature à mettre à risque la société au plan légal (certaines infos financières par exemple, ou des réorganisations et acquisitions), tout peut être expliqué avec un peu d’intelligence et de confiance.
Fournir des standards de performance
Être ouvert et approchable ne signifie pas être permissif. Mes meilleurs sponsors étaient intransigeants envers moi et mon équipe. J’avais très clairement leur support et je savais parfaitement ce qu’ils attendaient de moi. Nous avions de hauts standards de qualité et de performance et ils étaient partagés.
Développer une organisation qui apprend de ses erreurs et de ses réussites
Enfin, en tant que sponsor d’un projet important de la société et donc membre du senior management, je me dois de développer les compétences et le savoir-faire des ressources qui me sont confiées et m’assurer que les leçons apprises bénéficieront aux futurs projets.
Nous prenons la route vers la certification CMMI en mode projet
Voici un premier retour sur l’expérience de l’organisation de notre « voyage » vers la certification CMMI en mode Projet. Soyez indulgents car je ne prétends en aucun cas être un expert CMMI.
Comme beaucoup d’équipes informatiques, nous avons lancé des programmes d’Amélioration Continue. Ceux visent à accroître la qualité et la fiabilité des services que nous fournissons à nos clients internes. Sur le plan du développement de logiciel, il y a plusieurs initiatives que nous ciblons. Le défi le plus important que nous sommes donnés, en tant qu’équipe de management de notre informatique interne, est d’atteindre la certification CMMI.
Bien sûr, cela soulève de nombreuses questions :
- De quel niveau de certification CMMI avons-nous besoin et lequel est le plus approprié pour nos activités au vu de notre situation actuelle ?
- Lequel pouvons-nous nous permettre financièrement ?
- Dans quelle période pouvons-nous l’atteindre ?
- Pourquoi et avec quelles ressources ?
- Qui prend le leadership ?
- Qui décide ?
Pour atteindre un consensus et établir une direction claire, nous avons lancé cette initiative d’amélioration de notre performance comme un projet avec une responsable de projet et des sponsors seniors dans la communauté informatique. Après un certain nombre de sessions de travail entre les sponsors et la responsable de projet et son équipe, nous avons un plan d’attaque :
1. Dresser la carte de nos processus par rapport à CMMI et à ITIL pour nous assurer que nous avons une compréhension non ambiguë de quel standard utiliser pour chaque processus.
Par exemple, la plupart des processus de management de projet sont couverts par le Niveau 2 CMMI à l’exception du management des risques qui est de Niveau 3. Les étapes de définition initiales de notre cycle de vie des projets de développement de logiciel sont dans le périmètre du Niveau 2; alors que la conception, le développement et les tests relèvent du niveau 3 de CMMI. Des étapes postérieures comme le déploiement en production, le support et l’amélioration continue sont plutôt dans le périmètre ITIL…
2. Clarifier ce que les Niveaux 2 et 3 CMMI signifient pour nous
Bien sûr, nous avons des processus en place dans la plupart de ces secteurs. Cependant, nous sommes une organisation globale résultant de multiples fusions et d’évolutions successives au fil des ans. Aussi, il est important d’être clair sur la portée de chaque niveau pour décider comment se lancer au mieux et quel objectif devrait être le nôtre.
CMMI Niveau 2
Sept secteurs de Processus doivent être couverts pour une liste définie de projets qui devraient être représentatifs des activités de l’organisation : Gestion des Exigences, Planification de Projet, Suivi et contrôle de Projet, Gestion des approvisionnements et fournisseurs, Mesures et Analyse, Processus d’Assurance qualité de Produit et Gestion de Configuration
le Niveau 2 de CMMI est clairement centré sur le management de projet et des processus de support pour assurer qu’un jeu représentatif de projets de notre activité est :
- Managé avec des plans documentés et en conformité avec les règles établies
- Pourvu en personnel convenablement qualifié
- Contrôlé et suivi pour vérifier le progrès et assurer la participation des parties prenantes
- Contrôlé au niveau des livrables produits
- Fourni une bonne visibilité au management aux jalons définis
CMMI Niveau 3
Dix-huit secteurs de Processus à maîtriser (11 de plus que le Niveau 2) : Développement des exigences, Solution Technique, Intégration de Produit, Vérification, Validation, Processus de gouvernance, Formation sur l’Organisation, Gestion de projet Intégrée, Management des risques et Analyse de Décision et Résolution.
La portée à ce niveau est l’organisation toute entière et non plus un sous-ensemble de projets.
Tous les Objectifs du Niveau 2 doivent être atteints. Les processus standards d’organisation (des procédures, des outils, des méthodes etc.) doivent être définis, mis en œuvre et institutionnalisé à travers l’organisation entière.
CMMI Niveau 4 et 5: A voir plus en détail lorsque nous aurons atteint le niveau 2.
3. Évaluer les scénarios alternatifs dans notre situation pour être bien tous d’accord avec le niveau que nous visons et comment au mieux l’atteindre.
Pour nous, nous pourrions décider de partir pour :
1. Le niveau 2 de Maturité suivi par le Niveau 3 avec notre organisation entière
2. Allez directement au Niveau 3 de Maturité avec notre organisation entière
3. Le niveau 2 de Maturité suivi par le Niveau 3 mais avec une portée limitée (par exemple un sous-ensemble des domaines des applications logicielles)
4. Allez directement au Niveau 3 de Maturité, mais avec une portée limitée
Nous sommes arrivés à la conclusion que, dans notre situation spécifique, «le Niveau 2 de Maturité suivi du Niveau 3 avec notre organisation entière dans le périmètre» est la décision la plus appropriée. Les raisons sont que cela nous permet d’adopter une approche pas à pas; nous atteindrons des jalons intermédiaires qui valideront les efforts et progrès et augmenteront la motivation; cela facilite la gestion du changement car nous formons progressivement de plus en plus de managers et chefs de projets; cela assure la disponibilité nécessaire de l’infrastructure de processus quand nous nous lancerons dans l’objectif Niveau 3.
4. Définir et mettre en œuvre l’approche qui nous convient
Pendant la première étape, CMMI le Niveau 2, nous choisissons des projets au sein de notre organisation par rapport à leur criticité métier, complexité technique et budget annuel alloué. Pour la deuxième étape, préparer le Niveau 3, nous généraliserons les meilleures pratiques CMMI Niveau 2 à travers l’organisation. Ainsi, à la troisième étape, le Niveau 3, nous pourrons embarquer tous les projets dans le périmètre de la certification.
5. Tout au long du chemin parcouru, nous avons identifié nos Facteurs Critiques de Succès
- Engagement à 100 % des Leaders de l’informatique : nous avons passé du temps à expliquer l’approche, notre analyse et nos conclusions pour nous assurer que tous étaient à l’aise avec le projet avant d’engager l’étape 1.
- Gouvernance de projet : Nous avons voulu une gouvernance très simple et directe pour ce projet critique. Ainsi, la responsable de projet continue à travailler avec les mêmes sponsors qui étaient impliqués dans la préparation de la proposition initiale. Elle a accès à l’équipe de direction informatique sur une base régulière pour donner des nouvelles, éliminer les obstacles, prendre des décisions et maintenir la mobilisation générale.
- Les ressources sont clairement identifiées et nommées : l’effort requis pour entreprendre ce projet dans chaque équipe de développement ne doit pas être pas sous évalué. Il dépend en grande partie de votre point de départ, donc nos évaluations ne sont pas d’une grande utilité pour vous mais il est important que vous construisiez les vôtres avec réalisme et de manière conjointe avec les équipes de développement. Il est important d’être très clair dès le départ, par exemple : «chaque chef de projet dont le projet est dans le périmètre de la certification de Niveau 2 devra consacrer 4 jours par mois pendant la phase de démarrage (2-3 mois) et ensuite 2 jours par mois jusqu’à l’évaluation (6-9 mois)».
Conclusion (pour le moment)
Comme vous pouvez l’apprécier, le voyage CMMI n’est pas une ballade facile. Il exige de l’engagement, la clarté de but, le leadership et un management de projet rigoureux pour réussir.
Je vous garderai informés de notre progression.
Si vous vous êtes embarqués sur un voyage similaire, je vous invite à partager vos astuces de voyages vers la certification CMMI avec les lecteurs de ce blog …
Be the Chinese doctor of your projects. Watch their vital signs.
I posted a new article on the Blog Orange Business Live.
As a Chinese doctor, who is paid to keep his clients in good health rather than to look after them when they are sick, the project manager has to follow the vital signs of his project, and to address them before it seriously gets sick.
- Definition and implementation of concrete measures
- Critical path
- Respect for the schedule (variance of + or – 10 %)
- Current efforts and results reached compared to plan
- Projected costs and actual spend
- Quality of the deliverables
- Open Problems (number, time of resolution, age)
- Periodicity of reviews
- Management and control of the risks
- Morale of the team and human aspects
- Participation of the sponsor, involvement / satisfaction of the customer
- Anticipation by the trend analysis of the indicators
Read the full article and let me know which other vital signs of projects should be watched.
getting started on our CMMI certification journey as a project
This is a first return on experience about organizing our CMMI certification journey as a Project. Please bear with me as I am by no means pretending to be a CMMI expert.
As an internal Information Technology team, we have launched a number of Continuous Improvement programmes. These aim at enhancing the quality and reliability of the services we provide to our internal customers. On the development side, there are several initiatives that we are pursuing. The most important challenge that we set for ourselves, as an IT management team, is to reach a CMMI certification. Of course, this raises many questions:
- Which CMMI level do we need and is the most appropriate one for our activities?
- Which can we afford?
- In what timeframe can we reach it?
- Why and with what resources?
- Who leads?
- Who decides?
In order to reach consensus and establish clear direction, we launched it as a project with a clear project owner and senior sponsors in the IT community. After a number of working sessions between the sponsors and the project owner and her team, we had a plan of attack:
1. Map our IT processes to CMMI levels and to ITIL to ensure that we have a clear understanding about which standard is to be used for which process.
For example, most of the project management processes are covered by CMMI Level 2 with the exception of Risk Management that is Level 3. The initial definition steps of our Software Project life cycle are within Level 2 scope; while design, development and test are in CMMI level 3. Later steps such as deployment to production, support and continuous optimization fall into the ITIL best practices perimeter…
2. Clarify what CMMI Level 2 & 3 means for us
Of course, we have processes in place in most of these areas. However, we’re a global organization resulting from multiple mergers and evolutions over the years. So, it is important to be clear on the scope of each level to decide how to best get started and what objective should be ours.
CMMI Level 2
Seven Process areas need to be covered for a defined set of projects that should be representative of the organization’s activities: Requirements Management, Project Planning, Project Monitoring and Control, Supplier Agreement Management, Measurement and Analysis, Process and Product Quality Assurance and Configuration Management
CMMI Level 2 is clearly focused on project management and support processes to ensure that a set of projects representative of our activity are:
- managed using documented plans & in accordance with policy
- adequately staffed with suitably skilled resources
- monitored & tracked to check progress and ensure stakeholders involvement
- produce controlled outputs
- visible to management at defined points (milestones)
CMMI Level 3
Eighteen Process areas to master (11 more than Level 2): Requirements Development, Technical Solution, Product Integration, Verification, Validation, Organization Process Focus, Organization Process Definition, Organization Training, Integrated Project Management, Risk Management and Decision Analysis and Resolution.
The scope at this level is the entire organization rather than a subset of projects.
All Level 2 Objectives must be met. The organization’s set of standard processes (procedures, tools, methods etc) are to be defined, consistently implemented & institutionalized across the entire organization.
3. Assess the alternative scenarios in our own situation to agree to the level we’re aiming at and how to best get there.
For us we could go for:
- Maturity Level 2 followed by Level 3 with our entire organization in scope
- Go direct to Maturity Level 3 with our entire organization in scope
- Maturity Level 2 followed by Level 3 but with limited scope (for example a subset of the applications’ domains)
- Go direct to Maturity Level 3 but with limited scope
We came to the conclusion that, in our specific situation, « Maturity Level 2 followed by Level 3 with our entire organization in scope » was the appropriate decision. The reasons are that it allows us to adopt a step by step approach; we will achieve intermediate milestones that validate the efforts and progress and boost motivation; it facilitates change management as we progressively get more managers and PMs educated; It ensures availability of necessary process infrastructure when we embark upon the Level 3 objective.
4. Define and implementation approach that suits us
During the first step, CMMI Level 2, we are selecting projects across our organization based on their business criticality, technical complexity and annual budget. For the second step, prepare for Level 3, we will generalize CMMI best practices across the organization. So, that, at the third step, Level 3 certification, we can embark all projects an activities in scope.
5. Along the way we identified our Critical Success Factors
- 100% commitment of the IT Leaders: we spent time explaining the approach, our analysis and conclusions to ensure that all IT Leaders were comfortable with the project before engaging in step 1.
- Project governance: We wanted very simple and straightforward governance for this critical project. So, the project owner continues to work with the same sponsors who were involved in preparing the proposal. She has access to the IT leadership team on a regular basis to provide update, remove roadblocks, make decisions and keep the momentum going.
- Resources needs clearly identified and committed: The effort required to undertake such in each of the development shall not be under estimated. It will depend largely on your starting point, so our estimates are not relevant to you but it is important that you build yours with a very realistic mindset and jointly with the development teams. It is important to be very clear upfront, for example: « each project manager whose project(s) is/are in scope for Level 2 certification will have to spend 4 days a month in the startup phase (2-3 months) and then 2 days per month until the assessment (6-9 months) ».
Conclusion (for now)
As you can appreciate, the CMMI Journey is not an easy ride. It requires commitment, clarity of purpose, leadership and rigorous project management to succeed.
I’ll keep you posted on how well we progress.
If you have embarked on a similar journey, please share your CMMI certification tips with the readers of this blog…
Management du travail avec les Médias Sociaux pour les PMs
Article original de Ty Kiisel sur son blog.
Il y a quelques jours, Elisabeth Harrin du blog A Girl’s Guide to Project Management, a publié les résultats de son enquête sur Les médias Sociaux dans un Environnement de Projet (Social Media in a Project Environment). Un collègue m’a présenté l’étude sachant que je plaide pour l’incorporation d’aspects de communication et de collaboration des médias sociaux dans les outils de management de projets.
Harrin expose ses raisons de mener cette enquête, « Il y a de plus en plus d’évidence que les modes de travail s’adaptent pour inclure des outils des médias sociaux et que ceux-ci deviennent très répandus sur le lieu de travail. Tandis que des pratiques d’utilisation des médias sociaux sont bien établies pour le marketing, pour promouvoir les marques et accroître la proximité client, j’ai pensé que les chefs de projet devraient profiter des outils disponibles — et j’ai voulu découvrir si c’était le cas. »
Si vous suivez le lien fourni ci-dessus vous pourrez télécharger un PDF de l’enquête (qui est très informative). Cela étant dit, il y a deux ou trois points majeurs que j’ai trouvés intéressants :
1. Un des outils des médias sociaux le plus largement utilisé par des chefs de projet dans leur travail est Linkedin. 47 % des personnes interrogées utilisent Linkedin, ce qui me semble pertinent. Linkedin fournit une opportunité d’être connecté avec des amis et des pairs avec, de plus, la capacité de participer à une communauté plus large de chefs de projet. Comme je l’ai mentionné auparavant, la participation dans une communauté en ligne est une excellente manière de partager les meilleures pratiques et les expériences qui profitent en fin de compte à la fois aux individus et à la profession.
2. Les Wikis sont des outils sociaux collaboratifs populaires. Un outil utile pour encourager la collaboration et la communication, avec 35 %, il semble que beaucoup de chefs de projet utilisent les wikis.
3. À 24 %, il semble que les chefs de projet soient des bloggers actifs et des lecteurs de blog. Bien sûr un blog n’offre pas de capacité très pratique de collaborer pour des équipes de projet, mais comme les wikis, les blogs sont un bon endroit pour apprendre d’autres dans la communauté de management de projet.
4. Il est intéressant de noter que les outils de management de projets en ligne sont utilisés par 27 % des personnes interrogées. Pour quelqu’un qui fournit du logiciel de management de projet sur demande comme @task, C’est une bonne nouvelle.
5. Facebook, Twitter, SharePoint, MySpace, Microsoft LiveMeeting, Skype, la Messagerie Instantanée, les Podcasts et les Vidéo podcasts complètent le reste de l’enquête. Des scores aussi faibles que 1 % pour MySpace à 48 % qui s’identifient comme des utilisateurs SharePoint, les outils des médias sociaux semble être bien vivants dans le management de projet.
Les chefs de projet utilisent principalement les médias sociaux pour rester en contact avec amis et collègues. Cependant, le partage de document, la communication de changement de disponibilité, le partage d’informations de projet et même le suivi des tâches sont dans la liste. Je suppose que la question devient alors: « les médias sociaux fournissent-ils un avantage au projet en termes d’augmentation de la productivité ? »
La réponse semble être oui. 62 % des personnes interrogées disent avoir amélioré la communication tandis que 56 % revendiquent une amélioration de la collaboration. Selon Harrin, « Davantage de personnes indiquent des gains en efficacité plutôt que financiers et les deux bénéfices mentionnés le plus souvent sont l’amélioration de la collaboration et des communications. » Cependant, « Pas toutes les sociétés réalisent un suivi des avantages amenés par les outils médiatiques sociaux utilisés. »
La question finale de l’enquête était, « les outils des médias sociaux peuvent-ils améliorer la façon dont je manage des projets ? » 83 % des personnes interrogées ont répondu positivement.
Donc, je suppose que nous pouvons mettre un terme à toute la discussion sur l’utilité des médias sociaux puisqu’ils augmentent de manière évidente la productivité, non ? En fait, je ne le pense pas. Ceux qui ont répondu à l’enquête d’Harrin étaient déjà des utilisateurs des médias sociaux, qui lisent au minimum son blog, ce qui, à mon avis, biaise les résultats en faveur de l’utilisation des médias sociaux dans les processus de management de projet.
Cependant, je crois qu’il confirme vraiment qu’il y a les aspects des médias sociaux qui peuvent faciliter et même encourager la collaboration et la communication au sein des équipes de projet. Les outils des médias sociaux typiquement peu utilisés par la population examinée, comme Facebook et Twitter passent respectivement de 3% et 11 % pour ceux l’utilisant ces médias pour des raisons professionnelles à 23% et 29% pour ceux qui utilisent ces outils dans un cadre professionnel et personnel. Je crois que « comment ces médias sont utilisés » est plus important que l’outil lui même. Linkedin, blogs, podcasts et vidéo semblent être des manières très efficaces de partager les meilleures pratiques et de s’instruire, tandis que wikis, Twitter et Facebook offrent quelque chose qui encourage les personnes à interagir et à collaborer — des activités importantes pour réussir les projets.
J’ai pris le parti de rendre le logiciel de management de projet plus « social ». Je crois le logiciel de PPM qui incorpore ces fonctions de médias sociaux dans ses produits pour faciliter la communication et la collaboration fournira une valeur incroyable au processus de management du travail — ceux qui n’y parviennent pas deviendront obsolètes et inutiles.
Comment votre organisation se compare-t-elle aux résultats de cette enquête ?
Incorporez-vous des outils des médias sociaux dans vos processus ?
Petit conseil rapide : bien recevoir les remarques
Karen Tate de Http://www.griffintate.com/ a récemment publié le conseil suivant que j’ai trouvé très approprié pour des chefs de projet. Et, je suggère d’ajouter un huitième point qui est de définir votre plan d’action pour adresser les remarques qui vous semblent les plus importantes.
L’octroi et la réception de remarques sont essentiels à l’amélioration continue. Mais parfois la personne fournissant des remarques n’a pas les compétences pour développer et livrer un apport constructif. Dans ces cas, vous devez être capables de déployer des capacités d’écoute aussi efficaces qu’actives afin d’atteindre un résultat professionnel.
Voici sept (7) points clefs à se souvenir pour des résultats optimaux :
1. Reconnaître les faits.
2. Rester calme et se concentrer sur l’écoute. (Évitez de disputer et/ou d’être sur la défensive.)
3. Offrir son opinion seulement si on nous la demande.
4. Prendre du temps pour absorber le message avant de réagir. (Si une question est posée, demander si c’est acceptable d’y répondre plus tard pour avoir du temps pour préparer la réponse.)
5. S’assurer que vous comprenez le message avant de l’évaluer.
6. Être attentif au point de vue de l’autre personne.
7. Dire “merci.”
le PM doit être le médecin chinois de son projet
Tel le médecin chinois, payé pour garder ses clients en bonne santé plutôt que les soigner lorsqu’ils sont malades, le chef de projet doit suivre les signes vitaux de son projet afin de les adresser avant qu’il ne soit sérieusement malade.
- Définition et implémentation de mesures concrètes
- Chemin critique
- Respect du planning (variance de + ou -10%)
- Efforts actuels et résultats atteints par rapport au prévisionnel
- Coûts prévisionnels et dépenses avérées
- Qualité des livrables
- Problèmes ouverts (nombre, temps de résolution, âge)
- Périodicité des revues
- Gestion et maîtrise des risques
- Moral de l’équipe et aspects humains
- Participation du sponsor et implication/satisfaction du client
- Anticipation par l’analyse des tendances des indicateurs
Voici quelques-uns des signes vitaux de nos projets que je voudrais partager avec vous dans la suite de cet article publié sur le blog Orange Business Services live.
Compréhension de la Culture d’entreprise – Questions Clefs à vous poser
Un article original de Gina Abudi sur son blog: http://www.ginaabudi.com/understanding-the-corporate-culture-key-questions-to-ask-yourself
En rejoignant une organisation, indépendamment de votre rôle, il est important que vous preniez du temps pour comprendre la culture d’entreprise. Il y a différentes façons d’y parvenir, y compris en apprenant à connaître les autres départements et leur fonction/but dans l’organisation et en vous présentant à d’autres personnes dans l’organisation.
Pour comprendre la culture de votre organisation – ce qui vous aidera à mieux intégrer l’organisation et à y réussir dans votre rôle – répondez aux questions suivantes :
- Quelles sont les personnes clés dans l’organisation – celles qui réussissent, auxquelles ont fait appel quand des problèmes surgissent, qui prennent la parole régulièrement sans qu’on le leur demande, qui sont « visibles” dans l’organisation ?
- Comment les joueurs principaux dans l’organisation influencent-ils les autres ? S’expriment-ils fréquemment si quelque chose ne semble pas être juste ou s’ils ne sont pas d’accord ? Ou restent-ils silencieux parce que, de leur perspective, les choses ne peuvent pas tout simplement être changées ?
- Comment votre organisation travaille-t-elle avec d’autres départements ?
- Quels sont les processus et les procédures en place pour votre département ? Qu’en est-il de celles des départements avec lesquels vous interagissez régulièrement ?
- Quelles sont les règles de l’organisation ? Et les règles « tacites » ?
- Quelles sont les valeurs de l’organisation – qu’est-ce qui est le plus important pour eux ?
- Comment l’organisation interagit-elle avec ses clients – internes et externes ?
- Comment les décisions sont-elles construites et prises dans l’organisation ? Quels sont les joueurs majeurs pour des décisions stratégiques ? Qui est impliqué dans les prises de décisions non stratégiques?
- Quelles sont les priorités principales business pour l’organisation dans son ensemble – quels sont ses buts – cette année ? à 3 ans ? 5 ans ? 10 ans ? Plus long terme ?
- Quelles sont les priorités principales pour votre département – cette année ? à 3 ans ? 5 ans ? 10 ans ? Plus loin ?
- Comment communique l’organisation: au sein du département ? De département à département ? Avec les clients externes ? Depuis l’équipe de direction ? Quelle méthode est la plus efficace pour communiquer dans chaque situation ?
- Comment les réunions sont-elles exécutées dans l’organisation – face à face ? A distance ? Téléconférence ? Quelle est la meilleure manière pour vous de contribuer aux réunions de votre département ? Et pour les réunions avec la participation de divers autres départements?
Demandez à d’autres dans l’organisation ce qui leur permet de réussir dans leur job. Qu’ont-ils appris qu’ils peuvent partager avec vous pour vous aider à partir du bon pied et à être efficace dans votre rôle ? Les employés sont souvent enclins à aider de nouveaux arrivants en les guidant dans la bonne direction.
Quelles autres questions pourriez-vous poser pour parvenir à comprendre la culture de l’organisation ?
Comment comparer ScrumMaster et Chef de projet ?
Article lu récemment sur www.pmi.org de Lisa A. Grant, MBA, PMP, CSM: Http://www.pmi.org/eNews/Post/2010_03-26/ScrumMaster-Compare-To-PM.html
Un ScrumMaster peut-il être un manager de projet — les positions sont-elles identiques ? J’ai réfléchi sur cette question pendant environ trois semaines après être devenue ScrumMaster certifiée et ai conclu qu’elles ne sont pas les mêmes, elles sont plutôt deux rôles distincts. Cependant, un chef de projet peut remplir le rôle ScrumMaster et le fait même souvent.
Techniquement, Scrum, qui est une approche de développement logiciel Agile, est idéalement faite justement pour cela : le développement logiciel. En fait, elle est conçue pour le développement logiciel rapide par les membres d’une équipe fortement qualifiés et auto motivés.
Il y a, cependant, beaucoup d’activités dans le cycle de vie du développement logiciel qui ne sont pas directement reliées au développement de fonctions logicielles. Ces activités incluent le développement de Business Case, des activités de préparation opérationnelle, la formation et le déploiement en production, pour en nommer quelques-unes.
Les meilleurs ScrumMasters sont des leaders techniques, des architectes ou des managers. Ceux-ci sont des ingénieurs de développement logiciels seniors qui peuvent évaluer les tâches et offrir des conseils techniques dans le processus de développement. Ils sont destinés à être techniques.
Le chef de projet est la personne qui gère tous les aspects du projet, dont l’un est le cycle de développement du logiciel.
Le chef de projet est le manager d’ensemble, la personne responsable au niveau de projet, tandis que le ScrumMaster est le responsable du développement de livrables logiciels.
À la différence du chef de projet, le ScrumMaster manage :
- Le processus qui supporte si le logiciel répond vraiment au niveau fonctionnel aux besoins des parties prenantes (sous la direction du propriétaire de produit, le « product owner »);
- La justesse et l’adaptabilité de la conception technique; et
- Les tâches requises pour construire le produit de façon itérative en produisant un logiciel fonctionnel après chaque itération.
Le chef de projet s’assure que le business case est clairement défini, les documents de conformité sont correctement complétés, les activités de déploiement du produit bien exécutées — et il ou elle gère tous les autres aspects business du nouveau lancement de produit.
Il y a beaucoup de façons d’allouer les rôles par rapport aux ressources allouées au projet. Cependant, comme ils sont assignés dans un environnement Agile, je veux réitérer que Agile est destiné et a été conçu pour le développement de produits logiciels.
Il est possible d’utiliser Agile pour d’autres types de projets, mais la valeur pourrait être réduite à une liste de tâches avec un alignement de leurs dates de livraisons par itération. Une approche Agile performante fournit de la valeur pour le client à la fin de chaque itération, et pas simplement l’achèvement d’une liste de tâches.
La question à laquelle on doit répondre est : “Est-ce que le client a obtenu de la valeur avec ce que nous avons livré à la fin de l’itération ?” Si la réponse n’est pas positive, Agile n’est pas vraiment réussi.
Donc votre chef de projet joue-t-il aussi le rôle ScrumMaster ? Posez-vous ces questions :
- Le chef de projet a-t-il l’expertise technique d’évaluer des tâches techniques et de donner la direction ?
- Le chef de projet a-t-il été formé à Scrum ?
- Le chef de projet a-t-il le respect de l’équipe pour son expertise du sujet ?
Si la réponse à l’une ou plus des susdites questions est « Non », alors, laissez la personne qui a vraiment cette expertise exécuter le rôle de ScrumMaster. Si la réponse est « oui, » il ou elle peut probablement exécuter avec succès le double rôle de ScrumMaster et de chef de projet.
Rappelez-vous qu’il est difficile de garder une vue d’ensemble du projet ET une vue des tâches; c’est pourquoi il y a des chefs de projet. Pour équilibrer les deux rôles, les parties « business » du projet devront être mineures en comparaison du développement logiciel. De cette manière, le chef de projet/ScrumMaster peut se concentrer sur la gestion du temps et la facilitation des tâches de développement logiciels et les questions/problèmes et passer e reste du temps sur des activités comme le business case, le déploiement et la formation.
Si votre environnement évolue vers Scrum, ne présupposez pas automatiquement que le chef de projet devrait être le ScrumMaster. De plus, souvenez-vous qu’il y a toujours un rôle à jouer pour le chef de projet.
Ces deux positions devraient travailler de concert de même qu’un chef de projet et un manager de développement le font.
« what gets measured gets done », une épée à double tranchant
Le billet récemment posté sur Hooverbiz par Tim Walker m’a rappelé l’un des préceptes que j’avais appréhendés à la lecture du livre de Peter Drucker « Management Challenges for the 21st Century » (que je vous recommande).
La nécessité de mesurer ce qui doit être fait
J’aimerais tirer la sonnette d’alarme sur ce sujet.
Je n’ai aucun doute que, pour atteindre un objectif, il est important de bien définir les projets et tâches nécessaires à son accomplissement. Pour mesurer les progrès sur ceux-ci, il faut établir les métriques qui leurs sont propres et savoir les mesurer. Puis, il faut parvenir à cascader ces métriques sur les personnes qui vont les accomplir dans les objectifs organisationnels, d’équipes et/ou personnels, afin que tous travaillent dans la même direction.
Cependant, et sans vouloir paraître hérétique, si vous inversez le processus et observez chacune des mesures en place à l’heure actuelle dans votre environnement, la logique de cascade décrite ci-dessus n’est plus aussi évidente.
La nécessité de se poser les bonnes questions
Posez-vous les questions suivantes pour chaque mesure qui fait partie de vos objectifs personnels actuels et ceux de votre organisation (ou projet) :
- Quel objectif business nous aide-t-elle à atteindre ?
- Permet-elle effectivement de mesurer nos progrès vers ce but ?
- Quel est son coût d’obtention ou de calcul en rapport du bénéfice escompté ?
- Est-elle facile à comprendre ?
- Est-elle bien communiquée pour toute personne impactée ?
- Que se passerait-il si nous arrêtions de l’utiliser ?
Toute mesure, même bien ciblée sur un objectif précis, devrait avoir une durée de vie définie et être retirée ou remaniée dès que l’objectif est atteint sous peine d’accumulation de mesures inutiles, voire dangereuses. En effet, chaque mesure coûte à l’entreprise et, plus important, chaque mesure erronée peut avoir des conséquences graves quand elle est prise en isolation. Nombre d’entre elles entrent dans les mœurs et habitudes et nous oublions souvent de les questionner tant au niveau de leur adéquation aux objectifs qui peuvent avoir changés que de leur utilité et de leur mode de calcul.
Par exemple, si vous mesurez le nombre de tâches complétées dans les délais prévus par chaque membre de l’équipe sur votre projet et utilisez bien cette mesure, vous obtiendrez probablement une meilleure prédictibilité. Cependant, cela pourrait être au détriment de la qualité du contenu, de la satisfaction du client, de la capacité à réaliser certaines tâches plus rapidement que prévu ou bien éliminer certaines activités qui seraient inutiles…
On s’aperçoit donc rapidement que chaque mesure doit être bien pensée et pesée avant d’être implémentée. De plus, les mesures doivent être bien coordonnées entre elles pour se combiner harmonieusement pour atteindre l’objectif souhaité et ne pas être conflictuelles. Les mesures doivent être en nombre limité pour ne pas diluer notre attention et limiter les efforts nécessaires à calculer leur valeur.
Donner davantage d’oxygène au bon sens
Mais le risque peut-être plus important est de ne faire que ce qui va permettre d’améliorer les mesures. J’ai pu hélas souvent observer ce phénomène dans de grandes entreprises qui utilisent des mesures très sophistiquées. Il arrive que les personnes se focalisent sur les mesures qui vont faire évoluer favorablement leur bonus à court terme et perdent de vue l’intérêt de la société que leur dicterait leur simple bon sens. Ils sont ficelés, muselés dans leur créativité par un jeu de mesures trop restrictives et trop nombreuses.
Donc, il faudra éviter à tout prix que les mesures mises en place limitent la capacité de décision, l’autonomie, l’innovation, le respect du simple bon sens business. Et, pour ce faire, il convient de rester mesuré dans le nombre et intelligent dans l’implémentation de ses mesures.
tips to organize and keep your email inbox under control
I apply some basic principles to keep my inbox under control that I’ll share with you in this post.
Of course, they are not meant to be the best solution for your specific situation but they do work fine for me.
I’ll start with what I do NOT do.
I do not use my Inbox as my « to do » and « follow-up » lists. I use paper for these and find it most effective after trying many electronic versions. It may be because I memorize better when I write things manually, and it is also a routine to prioritize for the day tasks that are urgent, important and those than can wait.
I do not copy xillions of people on emails, only the ones who absolutely need to know in Carbon Copy and the ones who need to take action in destination « To: ».
I try not to send too many emails. The more you send, the more you receive.
Instead of systematically using email, I try to select the best communications media based on purpose. Instant messaging is way faster for short exchanges, questions, checking availability… Phone, conference call or physical meeting is best to resolve issues and address complex issues.
I do not mix professional and personal mailboxes. I try to totally separate work related emails from others. I never give my professional email address on any web site, social tools, registration forms… This way, I receive very few spams in my professional mailbox and I can easily handle private emails in a separate time window (most often early morning or lunch break).
Now, let’s see with what I actually do.
I have created folders on my hard drive with the same hierarchy as Microsoft Outlook folders for each project and key activities.
I detach all Outlook attachments to these directories using the « Attachment Remover » add on. This way the size of my mail file on the server and local disk remain reasonable (i.e. within our internal company limitations that are quite low).
I use 5 Outlook preferred « folders »: Inbox, Flagged , Unread, Sent, All Mails (for search). It’s an easy way to see at a glance how many new messages came in the Inbox, how many are flagged (Red, Yellow or Green, I’ll explain this further down the list), how many were automatically filed but unread (Unread – Inbox), how many I sent that may need to be filed for reference or future usage. I did surround the word folders above by quotes because « Unread » and « All Mails » are « search folders » rather that traditional filing folders.
I use rules to automatically file messages coming from specific email accounts or containing specific keywords in their title. This is especially useful for company news, admin items (expense claims, HR, newsletters, « comité d’entreprise »…). A count of the unread ones appears in the favorite folder called « Unread », so I can check them when I have time and they do not fill up my inbox. Once read, I usually delete these.
I usually read every e-mail that is not automatically filed within 24 hours
To get back to the topic « to do » and « follow up is required » emails. I use flags as follows:
All « to do » emails receive a red flag (until they are completed) and are filed in the appropriate folder for the project of activity they relate to.
- All « follow-up is required » emails are flagged in yellow and are filed in the proper folders.
- All « To Read Later » type emails get a Green flag and are then also filed in the proper folder.
I use Gmail Labels to do the same on my private inbox.
I review all red flagged e-mails daily and yellow ones at least weekly to ensure progress.
If the message requires a response (i.e. I’m on the to: list, or I really want to add something): I immediately respond when I think that it won’t take me more than a few minutes. The reason is that it is very time expensive to read multiple times the same email and put yourself back into context to answer. And I then file the message and my answer. When the response will take longer, I flag the message in red and file it in the appropriate folder based on the topic or project. When the response is to forward the message to a colleague or team member and follow up, I flag the message in Yellow, forward it with a note to explain why I am forwarding and file it in the appropriate folder.
I file or delete all other messages that do not require a response. The file or delete choice is arbitrary and, as a matter of facts, I tend to keep more that I delete (probably too much based on how often I need to retrieve such messages).
I do use mobile mail and I have it set up with manual synchronization. This allows me to read and respond to emails via the handset when it is an appropriate time for me rather than suffer constant interruptions.
As you can read, nothing fancy but it does work for me. What works for you?
why forcing unrealistic project dates is often counter productive
It is not rare that project dates, in particular the end date, are forced on the project manager and his team. Are they realistic? How were they estimated and approved? What is their foundation?
Here are some ideas to better handle this somewhat frequent problem.
The arbitrary…
Let’s keep in mind the 3 parameters of projects: any project can be represented as a triangle which summits are time, costs and contents. To freeze or force one of the summits often implies sacrifices on one of the other two.
Thus, fixing a completion date in an arbitrary manner can lead the project team to try to reduce the contents (the scope) to fit the timeframe. It can also drive costs up with the use of more resources to reach by all means the time target either with more resources, or superior skills or more expensive ones due to time pressure (reduced negotiation position) or all three. Naturally, these changes should generate the necessary discussions with sponsors and stakeholders to reach an agreement. If the compulsory date is absolutely unrealistic, it is of the duty of the project manager to pull the alarm bell and even consider refusing the project (must read: « Code of Ethics and Professional Conduct » of PMI).
On the sponsors’ side, it is necessary to be capable (I would even say that it is a duty) to explain the reasons behind the forced dates. These reasons can very well be valid and the project team, once it will have integrated them, will be motivated all the more to reach them.
A real life example was the implementation of a new accounting system at a big multinational firm. The sponsor of the team dedicated the necessary time to explain to all the stakeholders, project teams, future users, and management, the necessity of a launch of the new processes and application software on January 1st. Any delay would have caused big difficulties in data conversion and reconciliation at any other time during the year, i.e. additional pain for each person… The whole company was mobilized from then on; the deployment took place in time and was a success.
Rough estimates
There are many more or less scientific estimation techniques. The most wide-spread are the analog, parametric, intuitive methods or the experts’ advice, and « Bottom-Up ». Without going into too much details in this article, by analogy is about comparing a future project to similar already realized projects and extrapolating the estimates from this base. For example, if I have already implemented a software package in country X and I have to deploy the same product in country Y which of comparable size and complexity. I consider by analogy that the cost and the timeline for country Y will be sensibly the same as country X. The parametric method focuses at a high level at defining parameters that will allow estimating duration, efforts and costs. This is often used in Information Technology with parameters such as the number of screens, lines of code, interfaces between systems, and the other « Function Points » … The intuitive method is as its name indicates based on the personal appreciation of the estimator and it is mainly used to get quickly an order of magnitude. It is particularly useful upstream to prioritize approaches and downstream to identify potential incoherencies in the results produced by more detailed methods. The experts’ advices are often used to rationalize intuitive results. The experts draw from their experience and skills to provide their best estimates. 
Finally, the » Bottom-Up » method, more analytical requires much more detailed work at the level the deliverables of the project to estimate efforts, duration and costs. Generally, it is implemented via the Work Breakdown Structure of the project (WBS), and we try to estimate at the lowest level possible.
The best is to apply to several methods and compare the results.
Involvement of the team and the project manager
For the project to be successful, we will need that the team understands and 
signs off for the dates, even if imposed, as well as the effort estimates… If we take the example of Scrum in the software industry, at the beginning of each code development iteration (the Sprint), the members of the team often have the possibility of choosing themselves in the list prioritized by the customer (« product backlog ») which they take the commitment to realize over the period. They are completely engaged from then on with the task and the duration.
At minimum, the project manager must be able to be confident that he dates can be held in order to motivate his team on the duration, contents and quality.
Realistic and reachable plans
Realists for whom? First of all for the project team. As mentioned above, the project manager and his team are going to have to answer in a positive way the following questions: Will we succeed in delivering a product or a service that we we will be proud of in the allotted time? What sacrifices will it require and are we ready for these? Will we get the necessary support from our sponsors?
Maintaining a completion date in spite of the delays to start
This case is regrettably very frequent. The supplied estimates are correct and the end of September was reachable with January 1st start of the project. But, here we are, on March 9, and over the past three months sponsors and stakeholders hesitated, asked additional questions, did not manage to find time slots to meet… Finally, they saw each other this morning and agreed: we have the green light, this is great news! And (not as good) we are asked to respect the end of September completion and the budget!!! It will sound familiar to you, I am quite sure. However, unless we had inflated extravagantly our estimates (by 30 %) or are able to cut into the deliverables/contents, it will be mission impossible. Increasing the number of resources in such a drastic way at short notice does not seem plausible. One of the practices to be used to avoid as much as possible this type of situation is to include a milestone in the project’s critical path for the approval of the project (Project Approval Milestone – PAM). Then, express the next dates only as a matter of delays from this milestone date. For example, the analysis will be ended 2 months after the PAM, the design 4 months, the construction 8 months and the phase of test 9 months (PAM + 9 Months). I know, not easy in practice, but it is worth trying it.
Involvement of the customer
Is the date really convenient for the end customer? For example, to deliver a 
new booking system for a hotel just before peak season is probably not an excellent idea. Maybe would it be better to wait for the following quiet season and to enrich the features, or on the contrary, to minimize functionality to the bare minimum and deliver the system much faster? Also, in accounting some periods are to be avoided to deploy novelties: balance sheets, month end closure, invoicing runs, the tax declarations … It is thus advisable to make sure upfront of the relevance of forced dates coming from sponsors and stakeholders and not to assume that they are fully aware of the customers’ impact.
Resources
For a reason and another, totally independent from your will, it was not possible to you to recruit the resources in time: order forms blocked in purchases, slow controls by the recruiters, delays by certain managers to give the required skills to the project… Nevertheless the sponsors and the stakeholders are not willing to accept any delay!
In fact, they are probably right. It is our job as PM to anticipate, avoid or surmount this type of obstacles and to call upon sponsors to help remove any roadblocks before the project is negatively impacted.
à propos des risques à vouloir imposer des dates irréalistes
Il n’est pas rare que les dates du projet, en particulier celle de fin, soit imposées au chef de projet et à son équipe. Sont-elles réalistes? Comment ont-elles été estimées et agréées? Quel est leur fondement?
Voici quelques idées pour mieux appréhender ce problème somme toute très courant.
L’arbitraire…
Rappel des 3 paramètres: Tout projet s’inscrit dans un triangle dont les sommets sont le temps, les coûts et le contenu. Vouloir figer l’un des sommets implique souvent des sacrifices sur l’un ou l’autre des deux autres.
Donc, fixer une échéance calendaire de manière arbitraire peut amener l’équipe projet à essayer de réduire le contenu afin de tenir la date. Cela peut également conduire à un accroissement des coûts par l’utilisation de davantage de ressources pour atteindre à tout prix l’objectif de date ou bien des ressources de compétences supérieures ou de coûts plus importants. Bien sûr, ces deux alternatives généreront les discussions nécessaires avec sponsors et commanditaires pour arriver à un accord. Si la date imposée est absolument irréaliste, il est du devoir du chef de projet de tirer la sonnette d’alarme quitte à refuser le projet (voir le « Code of Ethics and Professional Conduct » de PMI ).
Coté sponsors et commanditaires, il faut être en mesure, et je dirais même se faire un devoir, d’expliquer le pourquoi de dates imposées. Ces raisons peuvent tout à fait être valides et l’équipe projet qui les aura intégrées sera d’autant plus motivée pour les atteindre.
Un exemple vécu fut la mise en place d’un nouveau système de comptabilité dans une grande entreprise internationale. Le sponsor de l’équipe avait pris le temps d’expliquer à l’ensemble des parties prenantes, équipes projet, futurs utilisateurs, et management, l’impératif d’un démarrage sur de nouveaux processus et applicatifs au 1er janvier. Tout retard aurait causé de grandes difficultés de reprise de l’existant pour l’année en cours, de travail supplémentaire pour chacun… L’ensemble de l’entreprise étant dès lors mobilisée, le déploiement se déroula dans les temps et fut un succès.
Estimations approximatives
Il existe de nombreuses techniques d’estimation plus ou moins scientifiques. Les plus répandues sont les méthodes analogique, paramétrique, intuitive ou avis d’experts, et « Bottom-Up ». Sans entrer dans les détails dans cet article, on estime par analogie en comparant un projet futur à des projets similaires déjà réalisés en extrapolant les estimations. Par exemple, si j’ai déjà implémenté un progiciel dans le pays X et je dois déployer ce même produit dans le pays Y qui de taille et complexité comparables. J’estime par analogie que le coût et les délais pour le pays Y seront sensiblement les mêmes que pour le pays X. La méthode paramétrique s’attache à un haut niveau à définir le ou les paramètres qui permettent d’estimer durée et coûts. Souvent utilisée dans le monde du développement logiciel avec des paramètres tels que le nombre d’écrans, de lignes de code, d’interfaces entre systèmes, et autres « Function Points »… La méthode intuitive est comme son nom l’indique basée sur l’appréciation personnelle de celui qui estime et elle sert principalement à donner un ordre de grandeur. Elle est particulièrement utile en amont pour prioriser les approches et en aval pour identifier des incohérences dans les résultats produits par des méthodes plus détaillées. Les avis d’experts sont souvent utilisés pour rationaliser les résultats intuitifs. Ce ou ces experts puisent dans leur expérience et compétences pour fournir des estimations les 
plus réalistes possible. Enfin, la méthode « Bottom-Up« , plus analytique exige beaucoup plus de travail détaillé au niveau de chaque livrable du projet pour en estimer efforts, durée et coûts. En général, elle est mise en œuvre grâce à la structure de décomposition du projet, le Work Breakdown Structure (WBS), et l’on s’efforce d’estimer les taches à réaliser au niveau le plus bas possible.
L’idéal est de faire appel à plusieurs méthodes d’estimation et d’en comparer les résultats.
Implication de l’équipe et du chef de projet
Pour que le projet soit un succès, il faudra que l’équipe projet s’approprie les dates, même imposées, ainsi que les estimations d’effort… Si nous prenons l’exemple de Scrum dans le logiciel, au début de chaque itération de développement sur le produit (le Sprint), les membres de l’équipe eux-mêmes ont souvent la possibilité de choisir dans la liste priorisée des besoins clients (le « product backlog ») les livrables qu’ils s’engagent à réaliser sur la période. Ils sont dès lors pleinement engagés sur la tâche et les délais.
Au minimum, le chef de projet doit pouvoir être intimement convaincu que les dates peuvent être tenues pour à son tour motiver son équipe sur les délais, le contenu et la qualité.
Plans réalistes et atteignables
Réalistes pour qui? En premier lieu pour l’équipe. Comme mentionné ci-dessus, le chef de projet et son équipe vont devoir répondre de manière positive aux questions suivantes: Parviendrons-nous à livrer un produit ou service dont nous serons fiers dans les délais? Quels sacrifices cela demandera-t-il et y sommes-nous prêts? Aurons-nous le support nécessaire de nos sponsors?
Vouloir maintenir une date malgré les retards au démarrage
Ce cas est hélas on ne peut plus fréquent. Les estimations fournies sont correctes et la date de fin septembre était atteignable en démarrant au 1er janvier. Mais voilà, nous sommes le 8 Mars et cela fait plus de trois mois que sponsors et financiers hésitent, posent des questions complémentaires, n’arrivent pas à trouver des créneaux horaires pour se rencontrer… Enfin, ils se sont vus ce matin et sont d’accord, nous avons le feu vert, bonne nouvelle! Et (moins bien) on nous demande de respecter la date de fin septembre et de ne pas dépasser les coûts!!! Cela peut vous paraître familier, j’en suis certain. Cependant, sauf à avoir gonflé outrageusement nos estimations (de 30%) ou pouvoir tailler dans le contenu des livrables, ce sera mission impossible, car accroître le volume de ressources de manière aussi drastique sur une aussi brève échéance semble peu plausible. L’une des pratiques à respecter pour éviter autant que faire se peut ce type de situation est d’inclure un jalon d’approbation du projet (JAP) dans le chemin critique du planning proposé et de n’exprimer les dates suivantes qu’en délais depuis cette date. Par exemple, l’analyse sera terminée 2 mois après le JAP, le design 4 mois, la construction 8 mois et la phase de test 9 mois (JAP + 9 Mois). Je sais, pas facile en pratique, mais cela vaut le coup d’essayer.
Implication du client
La date convient-elle réellement au client final? Par exemple, livrer un nouveau système de réservation hôtelière juste avant la saison touristique ne sera probablement pas une excellente idée. Peut-être vaudrait-il mieux attendre la saison creuse suivante et enrichir les fonctionnalités ou bien, au contraire, réduire celles-ci au strict minimum et livrer le système beaucoup plus tôt? De même, en comptabilité certaines périodes sont à éviter pour livrer des nouveautés: bilans, clôture de fin de mois, facturation, déclarations d’impôts… Il convient donc de bien s’assurer en amont de la pertinence des dates « imposées » par les sponsors et commanditaires et ne pas assumer qu’ils ont conscience de l’impact coté client.
Ressources
Pour une raison x ou y indépendante de votre volonté, il ne vous a pas été possible de recruter les ressources dans les temps: blocage des bons de commande aux achats, contrôles lent des recruteurs, réticences de certains managers à mettre à disposition les compétences requises… Pourtant les sponsors et commanditaires sont prêts à n’accepter aucun délai! En fait, ils ont probablement raison. C’est notre job de PM que d’anticiper, éviter ou surmonter ce type d’obstacles et de faire appel à eux pour faire sauter les blocages éventuels avant que le projet ne soit négativement impacté.
le PMBOK V4 est maintenant disponible en Français
|
|||
|
|||
|
|||
DantotsuPM.com 