samedi 27 avril 2013

Four Responsibilities of Executives on Projects

A lire sur:  Method123


1. Sponsorship and Funding

2. Escalations and Resolution
3. Monitor Projects
4. Coach Project Managers

7 Tips to Help Project Managers Track Their Tech Teams

A lire sur:


By Jennifer Lonoff Schiff
Thu, April 11, 2013
7 Ways Projects Managers Can Track Their Teams

[Related: 13 Tips for Keeping IT Projects Under Control]


vendredi 26 avril 2013

Create Schedule Management Plan

A lire sur:  Tenstep

The components of the Schedule Management Plan can include:
    • Schedule owner. This is probably the project manager.

Plus l'IT progresse, plus le DSI risque d'être dessaisi de ses missions stratégiques

A lire sur:

Edition du 24/04/2013 - par Bertrand Lemaire

L'informatique remonte dans la hiérarchie des entreprises devant l'importance stratégique du sujet. Du coup, soit le DSI monte d'un cran soit, désaisi, il se retrouve cantonné dans des tâches moins nobles. C'est ce que constate Stéphane Potier, Partner au sein du centre de compétences IT & Opérations du cabinet Roland Berger Strategy Consultants.
CIO : Qu'est-ce qui change dans les DSI en ce moment ?

Stéphane Potier : Les changements sont considérables depuis une dizaine d'années. On le constate avec l'évolution des profils des DSI : il y a dix ans, c'était toujours un technicien; aujourd'hui il est orienté de plus en plus « business ». On trouve même des anciens directeurs généraux d'entreprises plus petites prendre en charge la DSI de grands groupes. Les missions informatiques comme la production ou les études ont globalement peu changé. En revanche, les manières de procéder ont été bouleversées. La place du DSI change également considérablement.
L'IT devenant une préoccupation stratégique majeure, elle se retrouve de plus en plus, dans certains secteurs, sous la coupe, par exemple, de la Direction des Opérations - le « Chief Operating Officer » -. Certains DSI sont promus, d'autres n'ayant pas évolué en tant que Directeur des Opérations ou en DG baissent donc d'un cran - au moins - dans l'organigramme par rapport au PDG.

CIO : Sur les missions de production qu'est-ce qui a changé ?

Stéphane Potier : La production reste sur un mode « il faut que ça tourne ». Autrement dit : « pas de nouvelle, bonne nouvelle ». Mais les entreprises développent leur aversion au risque et doivent faire face à des réglementations de plus en plus contraignantes. Le patron de la production IT, voire le DSI, doit donc gérer le risque. Il doit être capable de garantir l'organisation contre des risques dont la gravité s'accroît avec la place croissante de l'IT dans le fonctionnement de l'entreprise. Par ailleurs, la manière de créer des centres de services partagés (CSP) est changée. Jadis, le responsable de CSP - souvent le DSI- arrivait en disant : « confiez-moi vos outils, je vais les industrialiser et réaliser des économies d'échelle. »
Or, l'industrialisation est longue à mettre en place. Elle commence par coûter de l'argent et les résultats sont hasardeux si on n'a pas toutes les cartes en main. Conséquence: les directions métiers voyaient surtout les coûts s'envoler. Le responsable de CSP doit donc (...)

Lire la suite dans CIO.PDF 62

mardi 23 avril 2013

Anatomie d’un email n°2 : l'objet

A lire sur:  ContactLab

Chaque élément de votre email peut faire la différence
L’objet, avec l’expéditeur, détermine en grande
partie le taux d’ouverture.

La majorité des messageries permettent de visualiser
les 45 à 50 premiers caractères de l'objet.
Vous avez donc très peu de place pour persuader, intriguer, surprendre, séduire
ou accrocher vos lecteurs afin de les inciter à ouvrir pour en savoir plus.
L’objet est aussi une promesse faite aux ouvreurs :
il faut ensuite la maintenir dans le contenu.
Les éléments les plus importants de votre message
doivent figurer dans les 30 premiers caractères
Quelques idées d’AB tests d’objets :
Factuel vs teaser
Long vs court
Promotion en pourcentage ou en valeur
Avec ou sans symboles
Avec ou sans nom du destinataire

jeudi 18 avril 2013

Watch Out for PM Mistake #5 - Poor Quality Results

A lire sur:;postID=6823866701843716481

This series of emails describes the five most common project management mistakes. In the past four weeks we have looked at a lack of planning (#1), poor scope change management (#2), not keeping your schedule up-to-date (#3), and poor project communication (#4).
Mistake #5: Poor quality leads to poor results
  • Rework. Rework means that you have to fix a deliverable that you thought was complete. Rework is always caused by flaws in your quality management process.
  • Higher operations costs. If errors are caught within the project, there is a cost associated with correct and rework. However, quality problems may surface after the solution is in operations. This causes operations (and maybe support) costs to increase.  
  • Client dissatisfaction. If a solution is of poor quality, the customer will not be happy. If the customer has a choice, they may not buy from you again. 
  • Missed deadlines and budget. Projects that build poor quality products tend to miss their deadlines and exceed their budget. This can cause the entire business case to be less attractive.
  • Poor morale. No one likes to work on a project that produces poor quality solutions. Morale and motivation tend to go down on these types of projects.
Don't fear. Quality management can help.
What Can be Done?
There are three main components to delivering quality solutions. 
  1. Quality requirements. You cannot meet the customers expectations for quality if you don't know what the expectations are. Quality requirements are identified when traditional functional and non-functional requirements are gathered.
  2. Quality control activities (QC). Quality control activities ensure the deliverables are of high-quality. This can include walkthroughs, completeness checklists, etc.
  3. Quality assurance activities (QA). These activities ensure that the processes used to create the deliverables are of high quality. This can include third party audits and checklists to ensure that a process were completed.
Everyone on the team needs to have a quality mindset to ensure that work is completed with a minimum amount of errors – the first time.

mercredi 17 avril 2013

Five Options for Project Start Dates

A lire sur:  Tenstep


Tolérances du projet (partie II)

A lire sur: Tenstep

Déclaration de réussite dans une perspective de projet
Une fois que vous avez compris ce que sont vos tolérances (s’il y en a), vous pouvez commencer à évaluer la réussite du projet. Généralement, les membres de l’équipe du projet peuvent déclarer la réussite, si:
1.     Le projet est livré dans les limites du coût estimatif, y compris la tolérance, en plus ou en moins.
2.     Le projet a été livré avant l’expiration de sa date limite, y compris la tolérance, en plus ou en moins.
3.     Tous les livrables principaux ont été accomplis (quelques produits mineurs ou des fonctionnalités mineures peuvent ne pas être livrés).
4.     La qualité globale est acceptable. (Elle n’a pas à être parfaite.)
Quelques entreprises vérifient également si le travail avec l’équipe de projet s’est bien déroulé, c'est-à-dire si le client et l’équipe de projet ont bien travaillé ensemble, s’il y a eu une bonne communication, par exemple. Si le client avait un autre projet (et le choix entre plusieurs entreprises), ferait-il appel à nouveau à la même entreprise ?
Déclaration de réussite dans une perspective d’entreprise
Du point de vue du projet, la déclaration de réussite relève normalement de la responsabilité de l’équipe de projet. Du point de vue de l’entreprise, votre réussite est également liée à la réalisation de la valeur ajoutée promise par les calculs initiaux de ROI. Si le projet est un échec du point de vue du projet, c'est normalement un échec pour l’entreprise également. (Bien que ce ne soit pas toujours le cas : certains projets dépassent leur budget et leur date limite. Pourtant, la solution est toujours considérée globalement comme une réussite commerciale.) Il y a également beaucoup d’exemples de projets qui ont été livrés avec efficacité, et ce, sans avoir produit la valeur ajoutée attendue. Si l’équipe de projet a bien livré les résultats dans les délais qui lui étaient impartis, il n’y a habituellement rien de plus qu’elle puisse faire. Cependant, il est possible que les calculs de rentabilité des investissements aient été biaisés, ou que le marché ait été mal jugé par le client et le commanditaire. Il est également possible que ce projet ait fait partie d'une plus grande initiative. Bien que votre projet soit réussi, l'initiative globale, plus grande, peut être un échec.
Chaque entreprise devrait suivre quelques règles générales pour déclarer la réussite ou l’échec d’un projet dans son ensemble. Votre projet n'est pas un échec si vous dépassez le budget d’un euro, et que vous le livrez avec un jour de retard. Normalement, un projet sera encore considéré comme réussi s'il est mené à terme dans les tolérances de coût et de durée, et qu’il fournit les principaux livrables avec une qualité acceptable. Dans une perspective commerciale globale, d’autres questions devraient être posées afin de savoir si la valeur marchande réalisée correspond aux attentes.
Terminologie de management de projet
Organisation par projets. Structure organisationnelle dans laquelle le chef de projet a toute autorité pour fixer les priorités, affecter les ressources et diriger le travail des personnes affectées au projet.
Planifier les communications. Processus qui consiste à établir les besoins en information des parties prenantes et à définir une approche pour les communications.
Abréviations courantes
EVM (anglais) : Earned Value Management
        (français) : Management par la valeur acquise

Five agile project management migration tips

A lire sur:

Takeaway: Rick Freedman shares five tips for PMBOK, CMM-style shops considering agile migrations. He also recommends an agile PM book that he says is a must-read.
I’ve written previously about the ideas and philosophies that form the foundation of agile project management. The history of project management, especially as it applies to IT, has resembled a pendulum, swinging from the lax controls and do-it-yourself ethic of the early mainframe “glass room” to the rigorous methodological controls and formal software development life cycles (SDLCs) of Project Management Body of Knowledge (PMBOK), Capability Maturity Model (CMM)-enforced practices. Many IT shops have fought painful ideological and cultural battles to make the transition to disciplined project management; in my career, I’ve seen the Project Management Institute (PMI) certification evolve from an obscure and unknown credential to a virtual requirement for employment in many organizations. We’ve also seen CMM certifications become critical differentiating factors, especially for offshore IT service providers, who have used CMM Level-5 certification as an “assurance factor” to help Global 500 firms feel comfortable outsourcing to far-off partners.
I’ve developed project management offices (PMOs) and project management methodologies for large IT firms and service shops, and I’m a strong advocate of adding these disciplines to the corporate toolkit to improve delivery consistency and process excellence. Now that I’m working with firms to train them in agile methods and to help them migrate to agile, however, I’m finding that these same disciplines that brought such strong benefits in project success rates can also be an impediment to agile adoption. Many firms have committed so completely to PMBOK process flows and CMM best practices that many of the core concepts of agile development, such as “barely sufficient” documentation and change-friendliness, seem like heresy.
In fact, I’ve had people in my Agile Project Management classes tell me that their perception of agile is that the key message is “everything you know about project management is wrong.” While this may in fact be the message of some purists in the agile community, I’m much more of a pragmatist, and my counsel to firms migrating to agile methods is that, not only can agile and traditional project methods co-exist, but in fact, in most organizations and for most projects, a hybrid approach is key to success.

Bridge to agile PM

In her outstanding book Software Project Manager’s Bridge to Agility, Michele Sliger walks readers through the PMBOK and relates agile concepts to the well-known Project Management Institute (PMI) knowledge areas and process areas. Sliger’s key message is that both the agile and traditional project management camps have misconceptions about the ideas and capabilities of the other side. Some PMI-focused PMs and organizations believe that PMI and the PMBOK don’t support agile methods, and that migration to agile automatically means abandoning PMI ideals. Conversely, some agile proponents believe that PMPs are so committed to “predictive” project methods that they can’t become agile. By relating the key practices of traditional PMOs, such as time, cost, and risk management, to agile approaches that address the same requirements in a slightly different way, Sliger demonstrates that the foundation disciplines of project management remain intact as your enterprise becomes agile, and that only some tactics and approaches change. For any enterprise considering migration from PMBOK-style project methods to more agile approaches, Sliger’s book is a must read.

Agile lessons learned

From my experience in the trenches, some of my key lessons learned for PMBOK, CMM-style shops are the following points:
  • Sell: Evangelizing the benefits and features of agile methods and ensuring that the sponsorship exists to make this often wrenching and difficult transition are prerequisites. Each of your audiences will need a different sales pitch; managers need to understand that agile teams can plan, that we do estimate, and that we can create a long-term strategic roadmap that gives them the information they need to budget and set expectations (ideas that conflict with agile myths). Development teams need to internalize the leaps in self-direction, creativity, and maturity that working in an agile environment can enable. Many agile teams observe that the expectation of self-direction encourages them to take responsibility and ownership of their commitments, and to develop mature skills like facilitation and negotiation. And PMO managers need to understand that their hard-won battles for discipline and consistency were not in vain.
  • Train: A robust training program for all audiences is the next key element of a successful transition to agile. The language is different, the development life-cycle is different, and the foundational philosophies of iterative development, constant customer involvement, minimal project management “ritual,” and change-friendliness must be understood and embraced for the organization to be united and prepared for the evolution ahead.
  • Pilot: Many organizations transitioning to agile select specific projects, typically suitable for an agile approach due to their innovative nature and their need to quickly respond to changes in the technical, business, or competitive landscape, and run them as “skunkworks” outside the standard PMO line of command. This allows development teams to quickly sidestep some of the process overhead that often accompanies SDLC-compliant programs, without requiring the organization to change its sanctioned approach without proof that agile works, and is suitable culturally for the company. To give a negative example, I recently worked with a team that is experimenting with agile methods, but is still also required to comply with strict PMO documentation and process requirements. This “double duty” is not a fair test of agile methods and, in fact, dooms agile to fail as it requires even more overhead, such as both burn-down charts and Gantt charts, and both story-driven and task-driven project plans.
  • Reflect: Once the team has a few agile projects under its belt, honestly reflect on what was best and worst about these efforts. These retrospectives should focus on the process of delivery and the actual deliverables, and should concentrate on the idea of balance and adaptiveness. Which elements of the existing, PMBOK-compliant methods must stay, because they add real value and also provide the predictability and comfort level management needs? Which agile methods have demonstrated that they can enhance the creativity and self-motivation of the team, and boost the collaborative spirit between the development team and the business sponsors?
  • Adapt: Adaptiveness is, in my view, the key to successful agile implementations. In fact, Jim Highsmith, a signatory of the Agile Manifesto and the author of the influential book Agile Project Management, uses the language of “adaptive development” as his core explanatory term for these methods. The agile approach that any enterprise adopts must be adapted to fit the culture, the risk profile, the history, and the preference of all the affected audiences. By experimenting with agile methods in some key “skunkworks” projects, honestly assessing their successes and challenges, and looking for the right mix and balance for your organization, your chances of a successful migration increase substantially.
Just as many firms took a long time to evolve from the “glass house” of mainframe development to the disciplined approaches of SMM and PMI, firms should expect migration to agile to be a process, not an event. Small steps are more easily digested by all audiences, and, although they may not bring the quantum leap in innovativeness and speed that a rapid agile adoption might, they make up for that by being acceptable and comfortable, and by preparing the way for success iteratively and incrementally, and iterative and incremental improvement is what agile methods are all about.

mardi 16 avril 2013

How to Work More Effectively

A lire sur:

Here are 5 tips to help you collaborate with your team, so that you can all work more effectively...
With more teams working in different offices, travelling and working at home these days, the chances are that some of your team members don't work in the same building as you from time to time. This can present a challenge: how can you work with them when you can't meet them physically?
Online collaboration tools are the easiest way to work effectively with people on a project, wherever you are. There are even benefits if you are all based in the same office space. So here are 5 tips to help you...
Tip 1: Keep all your discussions online
One of the most effective ways of working is to move everything online. Online collaboration software can help you do this, as it is designed for running projects on the web. The benefit of having all your project information and discussions online is that everyone can see the latest status at any time. You can even move your emails online into the software that you are using so that the whole discussion trail is in one place.
Tip 2: Use instant messaging
Instant messaging is great for getting the answer to a quick question, or checking if one of your colleagues is available for a longer discussion. You can archive your messaging trail securely online so that if you need to refer to it later it's there in your project files. It's faster and easier than email and once you start using it you'll never look back.
Tip 3: Share pictures
Do you know what all your team members look like? That might sound like a silly question, but if you are working with colleagues overseas or even in a different office, you may never have met them. Even if you have met them, chances are someone on your team has only ever talked to them on the phone. Upload photos to your team area so that you can see each other. It's easier to collaborate if you can put a face to a name!
Tip 4: Upload files
Stop sending huge email attachments by uploading all your core project files to a central online location. Using a document repository like this means that everyone always has access to the latest version, which can be a massive time-saver. It also means that people don't get frustrated looking for the latest copy and your IT department will be very happy that you aren't using your inbox as a document store!
Tip 5: Share calendars
It can be difficult to collaborate with team members if you don't know where they are. Sharing calendars means you can check if they are on leave or out of the office, and schedule meetings appropriately. You can also put key project milestones in the calendar so that everyone knows what is coming up without having to look at the project schedule. Make sure that you keep your own calendar up-to-date as well and include all the national holidays that are appropriate for your international team members, so you know when their offices are likely to be closed.

DSI et digital workplace, du passé faisons table rase ?

A lire sur:

Anthony Poncier

Anthony Poncier

Associé et «social business director» EMEA - Publicis Consultants Net Intelligenz
En savoir plus sur l'auteur
25 mars 2013
Mots-clés : Innovation, Management, Gartner, Anthony Poncier, entreprise 2.0, Jane Mc Connel, Europe

Pendant longtemps les DSI ont géré les dossiers liés au digital. Mais avec l'avènement du SaaS, beaucoup de métiers ont mis en place notamment des réseaux sociaux d'entreprises hébergés chez l'éditeur.

Une DSI désavouée ?
En partie désavoués dans leurs choix (même si certaines DSI ont compris qu’elles devaient faire évoluer leur rôle vers plus de stratégique et d’ouverture), beaucoup de directions des systèmes d'information restent accrochées à leurs vieilles approches projet. Et c’est sans parler de celles qui souhaitent développer leurs propres outils ou n’être qu’en lien avec un éditeur partenaire. Au final, de plus en plus souventc’estla direction de la communication, accompagnée des métiers et parfois de la DRH, qui prenden main ce type de projets digitaux limitant - au mieux -  la DSI à un rôle d’accompagnateursur le choix de l’outil. Ce schéma, pour caricatural qu’il soit, a largement contribué à faire la démonstration que ces questions n’étaient pas un problème d’outils, mais bien d’usage et de réponses à des besoins métiers. D’ailleurs une part non négligeable des projets relatifs à des questions IT et les budgets qui y sont liés, sont portés dorénavant par la communication et le marketing.
Quand Gartner annonce que 80% des projets collaboratifs vont "planter" à cause d’une vision outil, on se dit que peut-être certains enjeux n’ont pas été correctement abordés, notamment l’adhésion des utilisateurs finaux.
S'il ne s’agit pas de faire porter un chapeau trop large à la seule DSI, la question de leadership se posant aussi, force est de constater qu’un déploiement réussi de projet collaboratif est trop souvent anecdotique : la vision outil ayant primé sur le reste.
La montée en puissance des digital workplace
Peu importe, le nouveau projet à la mode est la digital workplace, incluant RSE, communication unifiée… Pour reprendre la définition de Jane Mc Connel : "Un écosystème de plateformes d’entreprise et de services qui permettent de travailler, collaborer, communiquer, développer des services et produits afin de mieux servir le client final". Tout est dans "écosystème de plateforme d’entreprise et de service". C’est le grand retour de la DSI, qui doit brancher tout cela avec le SI existant, et qui, malheureusement, transforme le tout  en grand portail de services de type "année 2000" ou en intranet à tout faire.
Et nous voilà repartis dans un long "effet tunnel" de plusieurs mois, avec des spécifications techniques à ne plus savoir quoi en faire. On repart à zéro. On fait table rase du passé. Oubliés les échecs liés à ce type d’approche !  Les temps de déploiements d’outils collaboratif sont multipliés et qu’importe que l’utilisateur final soit quelque part perdu dans les limbes du projet.
Comprendre que la réussite ne passe pas, par la multiplicité des fonctionnalités et des branchements, semble avoir été oubliée avec l’apparition de ce nouvel espace digital. Mais comme à toute chose malheur est bon, on assiste à un retour en force de la DSI et à une expertise dont elle est à la seule à pouvoir se prévaloir.
C’est la revanche de la DSI qui a du mal à reprendre la main sur les projets de RSE…  Question : même méthode et même échec en perspective ?

PROJECT MANAGEMENT MISTAKE #4: Poor project communication will cause many projects to end unsuccessfully

A lire sur:  Method 123

This series of emails describes the five most common project management mistakes. In the past three weeks we have looked at a lack of planning (#1), poor scope change management (#2) and not keeping your schedule up-to-date (#3).
Many years ago, a good project manager might have gotten away with being a poor communicator. The customers typically didn’t like it, but as long as the project manager could deliver the goods, the customer may have been inclined to let them do their own thing. In today’s world, however, projects need to be undertaken in partnership with the sponsor and customers, and this partnership absolutely requires solid communication. In fact, many of the problems that surface on a project are actually the results of poor communication. A project Communication Plan can help but still needs to be proactive. Poor communication can lead to the following trouble areas.
Differences in expectations
Project managers need to strive to ensure that all stakeholders have a common set of expectations. Perhaps it is just as simple as not informing some stakeholders that the project end date was changed from December 31 to March 31. People make decisions based on the information they have at the time, and if the project manager does not keep everyone under a common set of expectations, things can start to get out-of-sync fast.
People are surprised
If people are not kept informed as to what is going on, they will be surprised when changes occur. Proactive communication means that you keep people up-to-date. People get angry and frustrated when they find out bad news at the last minute, when there is no time left to have an impact on the situation. 
No one knows what the state of the project is
On some projects, people are not really sure what the status is. The communication on these projects is short and terse and does not give the reader a real sense as to what is going on. This leads to confusion and missed expectations.
People are impacted by the project at the last-minute
This is a prime cause of problems. In this situation, the project manager does not communicate proactively with other people about things that will impact them. When the communication does occur, it is at the last minute and everything is rush-rush. This frustrates people and leads to inevitable conflicts.  
Team members don’t know what is expected of them
Poor communication also occurs within a project team. Some project managers do a poor job of talking with their own team to explain what they are expected to do. This causes extra work and extra frustration on the part of the project manager and team members alike.
What’s the solution?
In most cases communication problems are not based on a lack of skills, but a lack of focus. Many project managers place communication on the bottom of their priority list. When they do communicate, it tends to be short and cryptic, as if they are trying to get by with the minimum effort possible.
The key to communicating is to focus on the reader - not yourself. Try to think about what the receiver of the communication needs and the information that will be most helpful to them. 
Many projects have problems. Poor communication can cause many problems and aggravate others. On the other hand, proactive communication can help overcome many other mistakes. Don’t consider communication to be a necessary evil. Instead, use it to your advantage to help your project go smoothly with less frustration, less uncertainty and no surprises.

mercredi 10 avril 2013

Seven Components to a Risk Management Plan

A lire sur:  Tenstep

The Risk Management Plan describes how you will define and manage risk on the project. This document does not actually describe the risks and the responses. This document defines the process and techniques you will use to define the risks and the responses. The information in this plan includes:
  • Roles and responsibilities. This section describes the leading and supporting roles in the risk management process. The project manager typically has overall responsibility for risk management, unless the team is large enough that this role can be delegated to another team member – perhaps a specialist. Third-party risk management teams may also be able to perform more independent, unbiased risk analyses of project than those from the sponsoring project team.
  • Budgeting. Discuss your budget for risk management for the project. Since you may not know enough to request budget for risk management you can also describe the process that you will use to determine a risk management budget estimate.
  • Timing. Defines when the initial risk assessment will be performed, as well as how often the risk management process will be conducted throughout the project life cycle. Results should be developed early enough to affect decisions.
  • Scoring and interpretation. You should define risk scoring and interpretation methods appropriate for the type of the qualitative and quantitative risk analysis being performed. Methods and scoring must be determined in advance to ensure consistency.
  • Thresholds. The threshold level is how you determine which risks are important enough to act upon.  The project manager, client, and sponsor may have a different risk threshold. The acceptable threshold forms the target against which the project team will analyze risks.
  • Communication. Describe how the information on risk will be documented and communicated. This includes the risks themselves, the risk responses and the risk status. 
  • Tracking and Auditing. Document how all facets of risk activities will be recorded for the benefit of the current project, future needs, and lessons learned. Also describe if and how risk processes will be audited.

Tolérances du projet (partie I)

A lire sur:  Tenstep

Le bulletin "Les meilleures pratiques de management de projet" contient des conseils pour vous assister dans la gestion de vos projets. Il présente chaque fois une autre facette de la méthodologie TenStep. Plus de 3 300 entreprises et consultants dans le monde entier ont déjà choisi TenStep – constatez-le par vous-même en cliquant ici.
Vous pouvez trouver tous les bulletins sur l’hyperlien suivant : Abonnement.

Tolérances du projet (partie I)
Vous avez tous lu des histoires au sujet du grand nombre de projets qui échouent. Selon les rapports que l’on lit, on apprend que plus de la moitié, voire 80% d’entre eux échouent! Selon ces mêmes rapports, plus le projet est grand, plus il y a de chances qu'il échoue. Cependant, si vous considérez les projets dans votre entreprise, diriez-vous vraiment que 80% d'entre eux sont défectueux? 50% d’entre eux seraient-ils même considérés comme des échecs? Il n'y a aucun doute que quelques-uns sont des échecs absolus. Ils subissent des accidents, sont annulés, prennent fin nettement au-delà du budget et de la date limite, ou sont inférieurs aux attentes. Cependant, y a-t-il vraiment 50% à 80% des projets qui correspondent à cette définition ?
Pour répondre à la question de savoir combien de projets ont échoué, vous devez d'abord comprendre la définition d'un projet raté. Le concept qui joue un rôle clé, dans ce contexte, est alors celui de tolérance. Si vous estimez qu'un projet coûtera 230.000 €, est-ce que votre projet est un échec si le coût effectif est de 230.500 €? Vous avez dépassé votre budget, n’est-ce pas? Oui, mais ceci entre dans la zone de tolérance. Si vous livrez avec moins de 500 € de dépassement sur un budget de 230.000 €, l’équipe devrait vous porter sur ses épaules et vous faire faire le tour des bureaux de votre entreprise, tellement cela relève de l’exploit.
Votre entreprise doit établir le niveau de tolérance qu’elle considère raisonnable pour ses projets. Dans certaines entreprises, par exemple, le niveau de tolérance varie de -10% à +5%.
Si vous fournissez le projet avec un dépassement de budget de 5%, il sera toujours considéré comme une réussite. Pour notre projet de 230.000 €, cela signifie que nous pourrions avoir un dépassement de budget allant jusqu’à 11.500 € et continuer à le considérer comme étant réussi.
D’autre part, si le coût final est en dessous de plus de 10% par rapport au budget, cela posera également un problème. Ici, le problème est que l’entreprise doit normalement livrer des projets qui répondent aux attentes : si le commanditaire avait su que le projet coûterait réellement beaucoup moins que ce qui avait été estimé, il aurait pu prendre d'autres décisions concernant le budget inutilisé. L'estimation des coûts doit être aussi précise que possible et devrait également inclure tout changement du contenu formellement approuvé. Si votre budget original était de 200.000 € et que le client a approuvé 30.000 € complémentaires dans le cadre des modifications du contenu, le montant final dont vous aurez la responsabilité est de 230.000€, plus les tolérances.
Normalement, il y a également des tolérances concernant les dates limites. Si vous estimez la durée d’un projet à six mois et qu’il est achevé en six mois et une semaine, cela est normalement acceptable. Votre date limite originale doit également être reportée si des modifications du contenu ont été approuvées. Naturellement, tous les projets n’ont pas cette flexibilité. Les projets de logiciels de passage à l’an 2000, par exemple, devaient être fins prêts pour le 31 décembre 1999. Une semaine de retard n’aurait pas été concevable.
Terminologie de management de projet
Organisation matricielle. Structure organisationnelle dans laquelle le chef de projet partage avec les responsables fonctionnels la responsabilité de fixer les priorités et de diriger le travail du personnel affecté à ce projet.
Planifier le management des risques. Processus qui consiste à définir les méthodes de conduite des activités de management des risques d'un projet. Aussi appelé Planifier la gestion des risques dans certains pays francophones.
Abréviations courantes
CV (anglais) : Cost Variance
EC (français) : Écart de coût

10 best practices for successful project management

A lire sur:


Given the high rate of project failures, you might think that companies would be happy to just have their project finish with some degree of success. That’s not the case. Despite the odds, organizations expect projects to be completed faster, cheaper, and better. The only way that these objectives can be met is through the use of effective project management processes and techniques. This list outlines the major phases of managing a project and discusses key steps for each one. Note: This article is also available as a PDF download.

1: Plan the work by utilizing a project definition document

  • Scope: What features of Exchange will be implemented? Which departments will be converted? What is specifically out of scope?
  • Approach: How will the migration project unfold and proceed?

2: Create a planning horizon

After the project definition has been prepared, the workplan can be created. The workplan provides the step-by-step instructions for constructing project deliverables and managing the project. You should use a prior workplan from a similar project as a model, if one exists. If not, build one the old-fashioned way by utilizing a work-breakdown structure and network diagram.

3: Define project management procedures up front

The project management procedures outline the resources that will be used to manage the project. This will include sections on how the team will manage issues, scope change, risk, quality, communication, and so on. It is important to be able to manage the project rigorously and proactively and to ensure that the project team and all stakeholders have a common understanding of how the project will be managed. If common procedures have already been established for your organization, utilize them on your project.

4: Manage the workplan and monitor the schedule and budget

  • Identify activities that have been completed during the previous time period and update the workplan to show they are finished. Determine whether there are any other activities that should be completed but have not been. After the workplan has been updated, determine whether the project will be completed within the original effort, cost, and duration. If not, determine the critical path and look for ways to accelerate these activities to get you back on track.

5: Look for warning signs

  • Team morale starts to decline.

6: Ensure that the sponsor approves scope-change requests

After the basics of managing the schedule, managing scope is the most important activity required to control a project. Many project failures are not caused by problems with estimating or team skill sets but by the project team working on major and minor deliverables that were not part of the original project definition or business requirements. Even if you have good scope-management procedures in place, there are still two major areas of scope-change management that must be understood to be successful: understanding who the customer is and scope creep.
In general, the project sponsor is the person funding the project. For infrastructure projects like an Exchange migration, the sponsor might be the CIO or CFO. Although there is usually just one sponsor, a big project can have many stakeholders, or people who are impacted by the project. Requests for scope changes will most often come from stakeholders — many of whom may be managers in their own right. One manager might want chat services for his or her area. Another might want an exception to the size limits you have placed on mailboxes. It doesn’t matter how important a change is to a stakeholder, they can’t make scope-change decisions, and they can’t give your team the approval to make the change. In proper scope-change management, the sponsor (or a designate) must give the approval, since they are the only ones who can add funding to cover the changes and know if the project impact is acceptable.

7: Guard against scope creep


8: Identify risks up front

When the planning work is occurring, the project team should identify all known risks. For each risk, they should also determine the probability that the risk event will occur and the potential impact on the project. Those events identified as high-risk should have specific plans put into place to mitigate them so they do not, in fact, occur. Medium risks should be evaluated to see whether they need to be proactively managed. (Low-level risks may be identified as assumptions. That is, there is potential risk involved, but you are “assuming” that the positive outcome is much more probable.) Some risks are inherent in a complex project that affects every person in the company. Other risks may include not having the right level of expertise, unfamiliarity with the technology, and problems integrating smoothly with existing products or equipment.

9: Continue to assess potential risks throughout the project


10: Resolve issues as quickly as possible
