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:

  1. Maturity Level 2 followed by Level 3 with our entire organization in scope
  2. Go direct to Maturity Level 3 with our entire organization in scope
  3. Maturity Level 2 followed by Level 3 but with limited scope (for example a subset of the applications’ domains)
  4. 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

Le PMI est heureux d’annoncer la sortie de la version française du Guide PMBOK® – Quatrième édition.

Le Guide PMBOK® – Quatrième édition poursuit la tradition d’excellence dans le management de projet avec une norme plus facile à comprendre et à mettre en œuvre, avec une plus grande cohérence et clarté.


Quoi de neuf ?

• Un langage normalisé a été incorporé dans tout le document de manière à favoriser la compréhension par le lecteur.
• De nouveaux diagrammes de flux des données clarifient les données d’entrée et de sortie pour chaque processus.
• Une plus grande attention a été accordée au mode d’intégration des domaines de connaissance dans le cadre des groupes de processus de démarrage, de planification, d’exécution, de surveillance et de maîtrise, et de clôture.
• Deux nouveaux processus sont présentés : Identifier les parties prenantes et Recueillir les exigences.

Les membres du PMI ont l’avantage de pouvoir accéder sans frais à la version numérique du Guide PMBOK®Quatrième édition.

The file is a watermarked PDF that includes your name and member ID. It is password protected with your PMI.org password and is licensed to you as a member benefit. La distribution, vente ou reproduction de ce fichier n’est pas autorisée.

Pour accéder à la version numérique :

1. Connectez-vous à PMI.org.
2. Click [enter URL]
3. Entrez votre mot de passe PMI.org.
4. Cliquez sur ‘Download’ [Télécharger].
5. Lorsque vous y êtes invité, sélectionnez ‘Save’ [Enregistrer] pour enregistrer le fichier PDF sur le bureau de votre ordinateur.

Pour ouvrir le fichier PDF :

1. Ouvrez le fichier PDF sur le bureau de votre ordinateur.
2. Lorsque vous y êtes invité, entrez votre mot de passe PMI.org puis cliquez sur ‘OK’.

Pour acheter votre exemplaire du Guide PMBOK®Quatrième édition :

• Visitez le site commercial de PMI.org (prix pour les membres du PMI : US$49,50) ou
• Renseignez-vous auprès de votre bureau local du PMI ou
• Utilisez l’ISBN à 13 chiffres pour passer votre commande en ligne à niveau local ou dans votre librairie préférée.

Beware not to confuse good idea with project / Attention à ne pas confondre bonne idée et projet

I wrote the following article for Orange Business Live in English and French.

Beware not to confuse good idea with project: Ideas are immaterial and often vague but the « raison d’être » of the project does not suffer approximations…

Attention à ne pas confondre bonne idée et projet

Les bénéfices de la Documentation de Projet

Voici un article qui m’a interpellé sur le blog de Gina Abudi. Il est écrit par  Dhanasekaran Sivaraj et sa version originale en anglais est lisible ici.

Documenter le projet ? ?

“Hummm…je préférerais passer ce temps sur d’autres activités plus importantes du projet.”

“Faisons-le après l’achèvement de toutes les activités du projet, pas tout de suite.”

“Je suis concentré sur la livraison du projet. La documentation peut attendre.”

“Je peux réaliser un projet de plus si je ne fais pas la documentation.”

Cela vous est familier ? Vous pouvez avoir entendu l’une ou toutes les excuses et les complaintes ci-dessus de beaucoup de chefs de projet, vous y compris. Ce sont des déclarations communément utilisées par les chefs de projet qui ne veulent pas faire un travail minutieux – ce qui signifie faire la documentation du projet. Si vous avez prononcé n’importe laquelle de ces phrases, il est temps de déposer une « Requête de Modification » pour changer votre perception de la documentation de projet.

La documentation de projet est un des secteurs les moins intéressants pour les chefs de projet car elle exige de nombreux efforts, mais est rarement applaudie par le chef. En réalité, cependant, la documentation de projet est un composant clef du management de projet et s’exécute du début à la fin de tout projet.

Examinons quelques points clefs à propos de la documentation de projet.

Pourquoi documenter ?

La documentation de projet est exigée pour réussir le projet. Elle est utilisée :

  • Pour définir le contenu du projet et s’assurer de l’accord de toutes les parties prenantes et des membres de l’équipe. Ainsi, toute personne impliqué dans le projet partage la même compréhension des attentes, de quoi faire, quand le faire, etc.
  • Pour établir une référence qui permettra de résoudre des différents et entre les parties prenantes si nécessaire.
  • Pour garder une référence historique qui fournit des informations détaillées sur le projet et peut être utilisée réussir de futurs projets.

Les bénéfices de faire la documentation de projet

En sus de ces raisons, la documentation de projet offre des avantages supplémentaires aux chefs de projet, y compris :

  • Une aide pour créer les Structures de Répartition de Travail (WBS) très détaillées qui aboutissent à l’élaboration de planning réalistes et réalisables.
  • Une diminution des surprises et risques inutiles.
  • Une aide pour prévoir l’avancement du projet pendant l’exécution et prendre des mesures proactives pour attaquer des défis.
  • Une compréhension claire des pré-requis de projet pour toutes les parties prenantes.

Et…le boss vous verra, le chef de projet, comme une personne soucieuse des détails et minutieuse dans son travail. Ce qui augmente votre valeur dans l’organisation et fait de vous un chef de projet désirable sur tous les projets majeurs.

Résultat final – changez votre perception sur la documentation de projet et commencez à vous concentrer davantage sur ce secteur. Vous commencerez à en voir les bénéfices en un rien de temps et vous augmenterez la probabilité de succès de vos projets avec moins de stress pour vous et pour l’équipe de projet.

Copyright © 2010 Dhanasekaran Sivaraj

Votre sponsor est-il aux abonnés absents?

Version anglaise de Ty Kiisel

Dans l’armée, si un soldat ou tout autre militaire quitte son poste sans autorisation, il ou elle est considéré « Absent Sans Permission ». Un soldat manquant laisse un vide — qui pourrait impacter négativement la mission. Chaque personne impliquée dans un projet, y compris le sponsor, a un rôle à jouer dans l’atteinte des objectifs du projet.

Tout plan de travail devrait mettre en évidence la participation des parties prenantes et du sponsor. Voici quelques suggestions pour garder les sponsors impliqués et participatifs :

1. Prévoyez des réunions régulières (généralement mensuellement) avec les sponsors, les membres de l’équipe et les autres parties prenantes importantes: Cela peut être l’opportunité d’une « rapide » mise à jour sur le statut; mais ce qui est plus important, c’est d’utiliser ce temps pour renforcer la valeur et la signification du projet en termes de business et d’engagement des sponsors à aider l’équipe.

2. Éduquez les sponsors sur leur rôle en tant que membres de l’équipe : les sponsors ont un rôle significatif d’avocats du projet auprès du comité de direction de façon à bien communiquer avec les parties prenantes et fournir la visibilité au management exécutif.

3. Ne négligez pas les opportunités impromptues de tête-à-tête avec les sponsors du projet : Assurez-vous que vos sponsors sont enclins à avoir des réunions informelles occasionnelles quand nécessaire. Il est important de cultiver la relation avec les sponsors — vos succès impactent leur succès et vice versa.

Garder les sponsors impliqués fait souvent la différence entre le projet qui réussit et celui qui échoue. Les outils de management de projet peuvent faciliter la communication avec les parties prenantes et les sponsors, mais indépendamment de votre manière de travailler, permettre aux sponsors de projet d’être aux abonnés absents n’est jamais une bonne idée.

Alors, comment empêchez-vous vos sponsors de « déserter » ?

Votre sponsor est-il aux abonnés absents?

http://blogs.attask.com/blog/strategic-project-management/0/0/is-your-project-sponsor-awol

Par Ty Kiisel

Dans l’armée, si un soldat ou tout autre militaire quitte son poste sans autorisation, il ou elle est considéré « Absent Sans Permission ». Un soldat manquant laisse un vide — qui pourrait impacter négativement la mission. Chaque personne impliquée dans un projet, y compris le sponsor, a un rôle à jouer dans l’atteinte des objectifs du projet.

Tout plan de travail devrait mettre en évidence la participation des parties prenantes et du sponsor. Voici quelques suggestions pour garder les sponsors impliqués et participatifs :

1. Prévoyez des réunions régulières (généralement mensuellement) avec les sponsors, les membres de l’équipe et les autres parties prenantes importantes: Cela peut être l’opportunité d’une « rapide » mise à jour sur le statut; mais ce qui est plus important, c’est d’utiliser ce temps pour renforcer la valeur et la signification du projet en termes de business et d’engagement des sponsors à aider l’équipe.

2. Éduquez les sponsors sur leur rôle en tant que membres de l’équipe : les sponsors ont un rôle significatif d’avocats du projet auprès du comité de direction de façon à bien communiquer avec les parties prenantes et fournir la visibilité au management exécutif.

3. Ne négligez pas les opportunités impromptues de tête-à-tête avec les sponsors du projet : Assurez-vous que vos sponsors sont enclins à avoir des réunions informelles occasionnelles quand nécessaire. Il est important de cultiver la relation avec les sponsors — vos succès impactent leur succès et vice versa.

Garder les sponsors impliqués fait souvent la différence entre le projet qui réussit et celui qui échoue. Les outils de management de projet peuvent faciliter la communication avec les parties prenantes et les sponsors, mais indépendamment de votre manière de travailler, permettre aux sponsors de projet d’être aux abonnés absents n’est jamais une bonne idée.

Alors, comment empêchez-vous vos sponsors de projet de « s’absenter sans permission » ?

10 minutes on your project with the big boss

I read an article written by Ty Kiisel that made me think about key things to have in mind when you get a chance to present your project to one or more senior executives.

His article is entitled « When Presenting to Stakeholders—You’ve Only Got About a Minute ».

Like Ty, I observed that a common trait of senior executives is that they’re often fighting for time. As a result, their attention span is quite limited and you better not waste the opportunity to address them when it arises. Having said that, everyone’s time is precious.  Time is something we get in very limited quantity when we come to birth. So, be concise, adapt your language to the other party, tease their interest, be specific…

All 10 tips proposed by Ty are certainly worth the lecture. I’d retain 3 as really key in my experience when it comes to presenting to senior executives and I would add one that I could not find in the list.

1. Big picture (personal addition): Remind them of the overall context of the project or issue that you want to discuss. Do not assume that they recall who you are or what your project is about. They have many things to juggle. So, start from the basics of how your project supports one or more of their strategic objectives for the company before diving into any detail. Then, provide a rapid overview of the project scope, investments, duration and key milestones. Position where you are at present against these.

2. Keep it simple: Be straightforward. Expose the facts and why their involvement is required.  Don’t overwhelm them with information, be concise, do not use jargon.  Doing otherwise would be a waste of time and they’ll think that you can’t synthesize a situation effectively or can’t express yourself intelligibly.

3. Always offer a solution: Offer a couple of options for a solution (but no more than 2). As pointed by Ty, there is no point in bringing up problems without potential solutions. They can decide between two solutions but it is your job to come up with well articulated options that highlight pros, cons, costs and project impact.

4. Specify the actions required of them: What exactly do you need from them? A memo or phone call to unlock a situation, more money, more time, more resources, arbitration, prioritization decision…

When Presenting to Stakeholders—You’ve Only Got About a Minute

I read an article written by Ty Kiisel that made me think about key things to have in mind when you get a chance to present your project to one or more senior executives. His article is entitled « When Presenting to Stakeholders—You’ve Only Got About a Minute ». (http://blogs.attask.com/blog/strategic-project-management/0/0/when-presenting-to-stakeholdersyouve-only-got-about-a-minute )

Ty is very correct that a common trait I observed with senior executives is that they’re often fighting for time. So, their attention span is quite limited and you need not to waste the opportunity to address them when you have one. Having said that, everyone’s time is precious.  Time is something we get in very limited quantity when we come to birth. So, be concise, adapt your language to the other party, tease their interest, be specific…

All 10 tips proposed by Ty are certainly interesting. I’d retain 3 as really key in my experience when it comes to presenting to senior executives and I would add one that I could not find in the list.

  1. Big picture (personal addition): Remind them of the overall context of the project or issue that you want to discuss with them. Do not assume that they recall who you are or what your project is about. They have many things to juggle. So, start from the outskirts of how your project supports one or more of their strategic objectives for the company before diving into any detail. Then, the project scope, investment, duration and key milestones. Position where you are at present against these.

  1. Keep it simple: Expose the facts and why their involvement is required in straightforward terms.  Don’t overwhelm them with information, be concise.  It would be a waste of time and they’ll think that can’t synthesize a situation effectively.

  1. Always offer a solution: Or a couple of options for a solution but no more than 2. There is no point in bringing up problems without potential solutions. They can decide between two solutions but it is your job to come up with well articulated proposals that highlight pros, cons, costs and project impact.

  1. Specify the actions required of them: What exactly do you need from them? A memo or phone call to unlock a situation, more money, more time, more resources, arbitration, prioritization decision…

B.A.-BA : répondre aux résistances

Dans un article précédent, j’ai décrit le B.A.-BA: pour conduire des entretiens téléphoniques efficaces. Dans cet article, je voudrais me concentrer sur quelques éléments essentiels pour répondre aux résistances pendant des appels téléphoniques ou des réunions, particulièrement si vous devez vendre un projet ou une idée. De nouveau, rien de neuf sous le soleil pour les chefs de projet expérimentés ou les professionnels de la vente. Mais, ce qui va sans dire, va encore mieux en le disant.

J’ai appris qu’il y a essentiellement trois types différents de résistance qui doivent être reconnus et gérés : Perception incorrecte, Scepticisme et Problème. En réalité, la manière de répondre dans ces trois situations n’est pas si différente mais voyons cela au cas pas cas :

1. Perception incorrecte

Avoir une perception incorrecte c’est soit percevoir inexactement ou bien mal comprendre. Vous vous trouvez dans une situation où, après avoir exposé votre topo, vous avez écouté activement votre interlocuteur. Vous remarquez que votre message n’est pas compris. Il peut y avoir beaucoup de raisons à cela : la manière dont vous vous êtes exprimé; des idées préconçues ou un manque d’écoute de la part de votre interlocuteur; un sujet trop complexe pour être compris du premier coup; un domaine qui exige des connaissances préalables que l’autre personne peut ne pas posséder … Ce qui est nécessaire dans cette situation c’est tout d’abord d’établir qu’il y a une mauvaise perception, de fournir ensuite une clarification et de conclure par une nouvelle écoute et un questionnement pour confirmer l’accord.

  • Établir qu’il y une mauvaise perception : prouvez, en répétant autant que possible les mots utilisés par la personne, que vous avez identifié une perception incorrecte. Précisez que la faute est la vôtre. Cette mauvaise perception ou ce malentendu est survenu parce que vous n’avez pas encore été capable de transmettre votre message assez clairement pour convaincre la personne.

Par exemple : «je vous entends dire que vous comprenez que ce projet durera 2 ans et exigera 10 membres du personnel de l’entreprise. Je vois que je n’ai pas été clair dans mes explications et je voudrais clarifier ce point spécifique.»

  • Fournissez la clarification sur l’élément qui n’a pas été bien compris.

Dans notre exemple : «le projet durera en effet 2 ans et nécessitera 10 ressources avec la portée actuellement définie. Cependant, une option présentée est de composer l’équipe à  50/50 entre internes et externes. De plus, une deuxième option est  de réduire la portée initiale pour obtenir la  plus grande partie possible  des bénéfices sur une période plus courte, si vous pensez que c’est souhaitable pour l’entreprise.»

  • Et concluez avec une nouvelle écoute et des questions pour confirmer l’accord.

Dans notre exemple : «j’ai vu que vous avez hoché la tête quand j’ai clarifié que nous pourrions pourvoir le projet avec 50 % de ressources externes. Sommes-nous d’accord que cette option est une bonne approche pour construire le projet ?»

2. Scepticisme

Le scepticisme s’apparente très souvent à des doutes et un désir de suspendre son jugement par rapport à de nouvelles informations qui ne sont pas très bien supportées par l’argument ou l’évidence présenté. Quand vous remarquez que les informations que vous avez fournies ne sont pas bien acceptées et que ce n’est pas en raison d’un malentendu, mais plutôt du scepticisme, vous êtes dans une situation qui exige l’assurance ou la réassurance. Donc, reconnaissez le scepticisme, rassurez et concluez par une nouvelle écoute et des questions pour confirmer l’accord.

  • Reconnaissez le scepticisme : vous anticiperez souvent cette réaction potentielle en passant en revue votre proposition ou argumentaire. Vous vous mettez vraiment dans les chaussures de votre homologue pendant un moment et essayez de voir depuis sa perspective ce qui pourrait être douteux dans votre projet ou idée. Dans certains cas, vous pouvez tout simplement vous remémorez que, lorsque vous n’étiez pas encore familier avec le projet, vous aviez également eu des doutes . Utilisez ceux-ci pour montrer que vous comprenez le scepticisme de votre interlocuteur.

Par exemple : « je vois que vous semblez avoir des doutes sur les 2 ans de durée et 240 homme mois d’effort. Très sincèrement, c’était également ma première réaction quand j’ai reçu ces évaluations. »

  • Rassurez sur le sujet qui génère du scepticisme. Si vous le pouvez, fournissez davantage de faits et preuves sur votre argumentaire. Des benchmarks ou des études, des chiffres de projets antérieurs, des références (particulièrement de personnes que votre homologue connaît bien), des précédents, des statistiques, … sont autant de sources que vous pouvez utiliser pour rassurer la personne sur le sujet.

Dans notre exemple : «Aussi, j’ai questionné l’équipe pour comprendre les détails. Et, ils ont été capables de me montrer les chiffres d’un projet précédent de complexité et portée semblables. Il avait coûté 360mm avec 12 ressources sur 2 ans et demi. Grâce à cette expérience, ils ont été capables de réduire la durée de notre projet à 2 ans et la taille d’équipe à 10 ressources au lieu de 12. Une amélioration de 30 % et avec une équipe qui a déjà réalisé un projet semblable.»

  • Et concluez avec une nouvelle session d’écoute et de questionnement pour accord.

Dans notre exemple : «vous avez semblé être sur la même longueur d’ondes que moi quand j’ai exposé la façon dont les évaluations ont été construites. Êtes-vous plus à l’aise avec cet aspect du projet ?»

3. Problème

«J’ai un problème …» est la méthode traditionnelle de remonter une préoccupation, un souci, lors d’une réunion. C’est une déclaration très puissante et qui, si elle n’est pas réglée, peut tout stopper. Si votre contrepartie ne l’exprime pas ouvertement, mais vous pouvez voir qu’il y a un problème réel pour lui ou elle, posez la question: «À votre avis, quel pourrait-être le problème-clé ou la préoccupation que le projet  devrait adresser  en priorité ?». De nouveau, ce qui est exigé dans cette situation est en premier lieu de reconnaître qu’il y a un problème, ensuite réaffirmer les points forts de votre proposition, chercher une résolution et conclure par une nouvelle écoute et des questions pour confirmer l’accord.

  • Reconnaissez le problème : assurez-vous que vous comprenez précisément le souci. Est-ce le coût, les délais, le contenu, l’approche, la dotation en personnel, les compétences, les conditions de paiement ? Prouvez, en réutilisant autant que possible les mots de la personne, que vous avez vraiment compris où se situe le problème.

Par exemple : «je vous entends mentionner comme un problème le fait que le projet durera 2 ans et exigera 10 membres du personnel interne. Et que la durée est une réelle préoccupation ou un point de blocage pour vous parce que votre fenêtre d’opportunité pour lancer ces nouveaux services sur le marché n’est que de 18 mois.»

  • Réaffirmez les points forts de votre proposition et utilisez des accords établis précédemment pour renforcer les bénéfices escomptés. Réitérez l’équation besoins/bénéfices du projet.

Dans notre exemple : «Nous avons établi ensemble que ce nouveau projet est absolument nécessaire pour permettre à la société de livrer ces nouveaux services. Des études préalables ont établi que des modifications  aux systèmes existants coûteraient davantage et demanderaient plus de temps. De plus, nous sommes d’accord sur la portée du projet en termes de contenu et d’évaluation des charges. Ce projet permettra aux nouveaux services d’être développés et exploités efficacement.»

  • Cherchez la résolution avec votre contrepartie pour éliminer ou contourner le problème.

Dans notre exemple : Ce projet durera en effet 2 ans avec 10 ressources pour la portée actuellement définie. Cependant, une option que nous avons examinée est de réduire la durée en amenant des ressources supplémentaires pour exécuter certaines tâches en parallèle plutôt que séquentiellement. D’autre part, nous avons également l’option mentionnée précédemment de réduire la portée initiale pour nous concentrer sur les fonctions les plus critiques. Celles qui permettront de répondre à la majorité des besoins sous 18 mois, avec quelques adaptations de processus. Puis, nous livrerons une version qui couvrira la totalité du périmètre un peu plus tard.»

  • Et concluez avec une nouvelle écoute et questionnement pour accord.

Dans notre exemple : «j’ai vu que vous avez été sensible à l’option d’ajouter du personnel externe sur le projet. Sommes-nous d’accord que ce serait une bonne approche pour avancer sur le projet ?»

Bien sûr, les chefs de projet ne sont pas des commerciaux professionnels, mais connaître quelque-unes des ficelles pour mieux répondre aux résistances pendant des réunions est une compétence fort utile dans nos vies professionnelle et privée.

B.A.-BA – conduire des entretiens téléphoniques efficaces

Je suis souvent étonné du manque apparent de professionnalisme dont font preuve certaines personnes dans leur manière de conduire des entretiens téléphoniques. En particulier lorsqu’ils ont lieu avec des clients, prospects, commanditaires, ou des niveaux de direction.

Je me demande si certaines des bases que nous avons appris très tôt dans notre vie professionnelle n’ont pas été oubliées. Dans mon cas, cet apprentissage s’est déroulé alors que les téléphones portables étaient « portatifs »,  la messagerie instantanée à inventer, sans parler des gazouillis de Twitter… C’était également une époque où les coûts de télécommunication étaient beaucoup plus élevés que de nos jours. Ceci explique peu-être pourquoi certaines de ces bases pourraient vous paraître dépassées. Pourtant, je les trouve encore extrêmement d’actualité dans mes communications téléphoniques.  Je considère qu’elles démontrent un respect envers mon interlocuteur et le temps qu’il ou elle me consacre.

Vu le temps que les chefs de projet passent sur ce type de communication, J’ai pensé qu’il pourrait être utile de partager la structure que j’essaie toujours de suivre.  C’est en fait très simple:

1. saluer la personne, se présenter et créer une atmosphère: si c’est une personne avec laquelle je parle souvent et connais assez bien, il est facile de rompre la glace avec quelques mots sur un sujet d’intérêt commun. Sinon, je reprends mes notes d’interactions passées ou je fais une rapide recherche Google , LinkedIn ou Viadeo pour trouver une accroche. Et, si la personne est référencée sur votre annuaire d’entreprise intranet, lisez sa fiche et regardez sa photo pour mettre un visage sur le nom.

2. positionner: confirmer le pourquoi de l’entretien et ses objectifs.

3. confirmer la durée: valider l’heure à laquelle l’entretien devra prendre fin et ne pas en déroger sauf sur demande de la personne appelée.

4. communiquer le plan de l’entretien: lister les sujets que vous aimeriez couvrir pendant cette session. Cela permet de se repérer pendant l’appel, cela évite les surprises, et aide à structurer l’appel et à gérer le temps.

5. écouter, valider l’accord: confirmer avec la personne que le plan proposé lui convient et demander si d’autres sujets devraient être ajoutés (ou certains enlevés).

6. dérouler l’appel en suivant le plan proposé et en s’assurant sur chaque point d’une compréhension commune par des questions de vérification et de validation.

7. faire un résumé de l’appel: Cette étape me permet de vérifier mes notes; de m’assurer que tous les sujets ont été couverts et si cela n’est pas le cas prévoir un appel ultérieur; et, d’expliciter ma compréhension de ce qui a été dit.

8. écouter, valider l’accord: Prendre le temps de vérifier que ma compréhension est correcte et que je n’ai rien oublié.

9. prendre note des actions: Il est temps de vérifier que nous avons bien un jeu commun d’actions agréées.

10. écouter, valider l’approbation: Pour confirmer nos engagements respectifs sur ces actions.

11. remercier la personne de son temps et contributions et pour les actions qu’elle a accepté de mener.

Ensuite, je m’efforce de ne jamais oublier de faire un suivi des actions sur lesquelles nous sommes d’accord.

back to basics for running effective calls

I’m often amazed by the apparent lack of professionalism some people demonstrate in running calls, especially with sponsors, customers, prospects, senior management…

I wonder if some of the basics we learned early in our careers have not been forgotten. In my case, I learned these when cell phones, instant messaging, tweets… did not yet exist, and also  at a time when telecoms costs were much more significant than Today. This may explain why some of these basics may seem a bit outdated. However, I personally still find them very very relevant in my day to day communications. I think that they also are a display of my respect towards the person I’m calling and for the time he or she dedicates to discuss with me.

Given time that Project Managers spend on calls, I thought that it could be useful to share how I always try to structure to be in good position. It is quite simple:

1. greet, introduce and relate: if I speak frequently with the person, it is quite simple to find « small talk » topics to break the ice. If I do not know the person very well, I’ll try to refer back to my notes from prior interactions, or perform a quick Google or LinkedIn search. And, if the person is referenced on the intranet directory, look at her information and picture to put a face on the name.

2. position: confirm the purpose and objectives of the call

3. confirm timing: confirm until when you have for this call and then do not overrun unless requested by the person you call

4. communicate plan: provide a rapid outline of the topics you’d like to cover during the call. It avoids surprises, it helps to structure the call and also it gives a way to check progress versus time allotted for the call.

5. listen/probe for agreement: confirm with the person that this plan is OK and ask if topics should be added or removed in their opinion.

6. run the call following the above plan and constantly probing, listening and confirming my/our mutual understanding

7. summarize the call: This step allows me to check my notes, verify that all topics we wanted to cover have been. And, if it’s not the case agree to a follow up call. Repeat my understanding of what has been said.

8. listen/probe for agreement: Take the time to check that my understanding is correct and verify that I haven’t missed any point.

9. propose actions: Now it’s time to double check that we have a common set of agreed actions.

10. listen/probe for commitment: This is to confirm our respective commitments to conduct the above actions

11. thank the person for their time and contributions and for accepting some of the above actions.

Then, I try to never forget to follow through on the actions we agreed.

20+ questions for a « lessons learned » session at the end of your project

Over time, I gathered from various sources a number of questions that I find appropriate to consider with the team at the end of a project.

Governance and Communication

1. What did the project committee do well that could be reused on future projects?

2. Where could it have done a better job?

3. How well were the organizations and users informed about the project?

4. Were appropriate communication channels and media used?

5. Did various audiences receive appropriate, timely information about the project?

6. Was too much or too little information communicated at any stage?

Change Management

7. What changes were requested or introduced during the project?

8. Did the changes prove to be valuable, e.g., increased benefits, lower overall costs?

9. Were any project objectives compromised through the introduction of a change?

Risk Management

10. How many anticipated risks materialized, and how were they managed?

11. How many unanticipated risks materialized, and how were they managed?

12. What risks were well managed, and which could have been better handled?

13. Did we spend the appropriate time on risk management?

Time Management

14. Was the project delivered on time? If not, please provide reasons with examples and any mitigation factors.

15. Was project governance timely established?

16. Did the governance help make effective, timely decisions for the project’s benefit?

17. Is everything in place to rip the benefits as soon as possible?

Finance Management

18. Has the project completed a review of its business case at the end of the implementation?

19. How do the actual project costs compare to the original estimates?

20. What did cost more than budgeted, what did cost less, and why?

21. How could costs be reduced on future, similar projects without compromising success?

22. Were the benefits reached on time with appropriate business ownership?

Quality Management

23. Has the project met its quality objectives?

Project Support tools

24. How well or badly were the support tools for the project assisting you and how well did they work?

Une bonne vingtaine de questions à considérer pour vos sessions « Leçons apprises » de fin de projet

Au fil du temps, j’ai accumulé de diverses sources pas mal de questions qu’il me semble utiles de se poser avec l’équipe en fin de projet.

Gouvernance et Communication

1. Qu’est-ce que le comité de projet a réussi qui pourrait être passé aux futurs comités de projet ?

2. Où aurait-il pu faire mieux ?

3. Comment était le niveau d’information du business et des communautés d’utilisateurs ?

4. Les canaux de communication et médias déployés étaient-ils appropriés?

5. Les diverses audiences ont-elles reçu des informations appropriées, au bon moment sur le projet ?

6. Est-ce que trop ou trop peu d’informations ont été communiquées à un moment donné ?

Gestion des Changements

7. Quels changements ont été demandés ou introduit pendant le projet ?

8. Les changements ont-ils démontré la valeur, par exemple, des bénéfices accrus, des réductions de dépenses globales ? Si non, merci de donner des exemples concrets.

9. Quels objectifs du projet ont été compromis par l’introduction d’un changement ?

Gestion des risques

10. Combien de risques prévus se sont réalisés et comment ont-ils été managés ? Si non, merci de donner des exemples concrets.

11. Combien de risques imprévus se sont réalisés et comment ont-ils été managés?

12. Quels risques ont été bien gérés et lesquels pourraient avoir été mieux gérés ?

13. Avons-nous passé le temps approprié sur la gestion des risques ?

Livraison dans les Temps

14. Le projet a-t-il été livré à l’heure ? Si non, merci de donner des raisons à partir d’exemples concrets.

15. La gouvernance de projet a-t-elle été établie au bon moment ?

16. L’équipe de gouvernance a-t-elle pris des décisions efficaces, opportunes pour le bénéfice du projet et du business ?

17. Tout est-il en place pour réaliser les bénéfices le plus tôt possible ?

Gestion Financière

18. Le projet a-t-il complété sa revue de business case de fin de projet?

19. Comment les dépenses effectives du projet se comparent-elles aux évaluations de pré-projet ?

20. Qu’est-ce qui a coûté plus que budgétisé ou bien moins et pourquoi ?

21. Comment les dépenses pourraient-elles être réduites à l’avenir sur des projets semblables sans mettre en péril les objectifs de projet ?

22. Est-ce que le plan de réalisation des bénéfices a été atteint dans les temps avec un bon engagement business?

Management de la qualité

23. Le projet a-t-il atteint ses objectifs de qualité ?

Outils de support du Project

24. Les outils de support du projet ont-ils bien supporté votre travail et ont-ils bien marché ?

Quelles questions ajouteriez-vous à cette liste?