Archives de Tag: la gouvernance

Dites-moi comment vous me mesurez, je vous dirai comment je me comporte ! par Isabelle Icord

24 avr
Eli Goldratt - The Goal

Cliquer sur cette image pour le livre

Cette phrase « Dites-moi comment vous me mesurez, je vous dirai comment je me comporte » est une citation d’Eliyahu Goldratt, inventeur de La Théorie des Contraintes (Theory of Constraints, le plus souvent abrégée en TOC) qui désigne l’ensemble des concepts constituant la compréhension qu’a eu Eliyahu Goldratt des organisations et de leur management. Un des objectifs de la TOC est de traiter les problèmes complexes et de proposer, pour les résoudre, des approches pragmatiques et ancrées dans la réalité, des approches également systémiques, pour mieux tenir compte de la complexité apparente de nos organisations.

Examinons comment cette simple affirmation peut nous aider dans le pilotage de nos organisations et de nos projets.

Une illustration dans la planification et l’exécution des projets

Un livre de Isabelle Icord

Un livre de Isabelle Icord

Beaucoup de chefs de projets, de responsables de développements, de directeur de PMO ou de managers avouent que l’un des challenges récurrents du projet est de veiller à bien en respecter la durée. Ils font parfois la décevante constatation qu’ils sont les seuls à vraiment s’engager sur la date de fin de projet, chaque intervenant se concentrant souvent plus sur la partie technique de la tâche lui incombant que sur le rendu en temps et en heure.

Et bien, cela va changer ! Pour le prochain projet, c’est sûr, chacun va s’engager sur une estimation de durée et la mesure de performance sera faite en fonction du respect de cet engagement. D’ailleurs, dernière bonne idée du jour, nous allons mettre en place un indicateur de respect des engagements. Et gare à celui qui dépasse le temps imparti à sa tâche !

Quel comportement va donc pousser un tel indicateur ?

croire en soi et ses capacitésA n’en pas douter, il va inciter les ressources à faire une estimation robuste de la durée de leurs tâches. Souvent, la robustesse d’une estimation passe par la capacité de celui qui la fait à envisager le pire (toujours possible d’après Murphy, et force est de constater que Murphy est souvent présent dans nos projets !).

Le pire, c’est l’aléa imprévisible, la difficulté technique mal évaluée, l’urgence de production qui stoppe l’avance des développements, ou bien encore les incessantes interruptions ou demandes « sauvages » générées par l’organisation. Ayant en tête bon nombre de ces expériences négatives, la personne responsable de l’estimation va tenir compte, tout à la fois du système dans lequel s’effectue la tâche, mais aussi de la complexité, de la nouveauté ou du challenge demandé. De plus, pour faire preuve de professionnalisme et comme gage de confiance, elle aura à cœur de faire rouler les désfaire une estimation fiable, sur laquelle elle puisse raisonnablement s’engager, c’est-à-dire une estimation ayant une forte probabilité de se réaliser, quelque soit le contexte perturbé dans lequel le projet évolue. A bien y réfléchir, le futur n’est que probabilités. Cette estimation va donc nécessairement inclure de la sécurité, utile pour faire face aux aléas inévitables des projets. Pour autant, l’ensemble des tâches constituant le projet seront-elles terminées à temps, conformément à l’estimation initiale ?

Pour tous ceux qui ont déjà expérimenté cette approche et qui ont poussé les ressources à s’engager sur une estimation de durée, la réponse est non : dans ce mode de fonctionnement, les projets sont systématiquement en retard, encore plus certainement d’ailleurs que précédemment. Et cela à cause des comportements qu’induit une date de fin figée pour une tâche.

Falling Domino Pieces Arranged in a LineSi le travail commencé avance bien et que respecter son engagement n’est plus perçu comme un challenge, il est tout à fait humain d’accepter de se laisser déranger par d’autres tâches, d’autres demandes, d’autres urgences. La focalisation est perdue, nous nous sommes fait piéger par le sentiment qu’il est plus important de commencer autre chose plutôt que de finir rapidement ce qui est en cours. Pourtant, les 10% restant d’une tâche ne sont pas les plus facile à faire et peuvent également réserver d’ultimes et désagréables surprises, qui viendront fragiliser voire hypothéquer l’engagement pris de finir la tâche à l’heure.

D’autres comportements nous poussent à traiter d’abord les urgences avant de se mettre sur cette tâche. Peut-être aussi à finir les précédents efforts sur lesquels notre engagement est mis à mal. Commencer en retard une tâche dont la date de fin est figée n’est certes pas la meilleure façon de gérer le temps disponible pour l’aléa : celui-ci est « perdu » avant même le démarrage effectif de la tâche, qui, pour finir à temps, n’a d’autre alternative que de ne rencontrer aucune difficulté inattendue. Ce comportement (connu sous le terme de « syndrome de l’étudiant ») est de fait induit par la date de fin de la tâche.

Ainsi donc, un système qui valorise au travers d’indicateurs, une date de fin, au détriment d’un démarrage piloté par un compte à rebours et d’une focalisation jusqu’à la fin de la tâche, est un système qui induit des dérapages inévitables de tâches, et par effet domino de projets. L’indicateur de respect de la durée des tâches pousse à mettre des sécurités et nos comportements humains nous les font naturellement gaspiller : notre système est une formidable machine à cumuler les retards alors que notre objectif était juste inverse !

Pourquoi ne pas valoriser plutôt la vitesse d’exécution que la date limite ?… Et ce à travers un indicateur qui poussera ce comportement.

SMPP

Partenaire de DantotsuPM

Pourquoi est-il préférable d’agir sur le système…

L’exemple précédent illustre à quel point le système dans lequel nous évoluons induit certains de nos comportements aux détriments d’autres. Si nous partageons cette approche, nous voilà mieux armés pour faire évoluer positivement les acteurs du système : non pas en essayant de les changer. Nombreuses sont les études et les situations qui prouvent à quel point il est illusoire de vouloir changer les gens. Les changements humains et profonds ne se décrètent pas ; ne dit-on pas d’ailleurs « chasser le naturel, il revient au galop » ?

Pour des changements pérennes et efficaces, mieux vaut agir sur le système, à travers l’influence qu’il opchangesère sur notre comportement. C’est en changeant de façon pertinente certains paramètres du système que nous pousserons des comportements, certes moins naturels chez certains mais globalement bénéfiques aux organisations. Une illustration connue de ce point de vue est le comportement d’une équipe achat : si l’indicateur de performance de cette équipe est de trouver toujours un fournisseur moins cher, fort est à parier que l’équipe privilégiera cette option plutôt que celle d’un fournisseur capable par exemple de respecter ou d’accélérer un temps de cycle. Dans un projet, cela revient à faire une économie de coûts, localement pour le poste achat, au détriment du délai global du projet… Cela vaut-il vraiment le « coup » ?

Man Climbing a LadderAinsi donc peut-on affirmer que les acteurs d’un système ne sont pas fondamentalement bons ou mauvais, ils sont conformes à ce qu’induit le système, de bon… et de mauvais. Prenez un ensemble de personnes brillantes et performantes et faites les interagir dans un système médiocre, elles deviendront à n’en pas douter aussi médiocres que ce système. A l’inverse, rassemblez dans un système performant des personnes « moyennes » (pour peu que cela ait un sens…), elles formeront une équipe bien plus performante que moyenne !

Quel système voulez-vous pour vos projets, pour vos organisations ? Quel management pour piloter vos transformations ?

SMP2

téléchargez le référentiel

Approfondissez cette réflexion en vous imprégnant de la pratique de pilotage de projets et portefeuille par la Chaîne Critique et en appréhendant la démarche SMP2.

La gouvernance est une science complexe ! Plusieurs référentiels ou modèles de maturité sont à la disposition des Directions qui souhaiteraient mettre sur une même page leurs ressources, leurs visions de l’organisation et des transformations. SMPP, porté par la Communauté (SMP2®) (experts, démarche et outils dédiés au déploiement du référentiel SMPP) est l’un d’entre eux.

Isabelle Icord

Isabelle Icord

Isabelle ICORD,Fondatrice et directrice de Pro CC (http://www.procc-conseil.com) a 20 ans d’expérience en pilotage de projets internationaux de développement en entreprise. Experte de la pratique de la Chaîne Critique et à l’origine des toutes premières implémentations pratiques de ce concept en France, avec une expérience récente et réussie de mise en œuvre chez e2v semi-conducteurs Grenoble. Auteure d’un programme complet de formation vidéo sur la CCPMBoost Project System (boost-project-system.fr) et d’un livre « La Chaîne Critique en pratique »

 

 

l’acte de la signature manuelle reste important sur les projets !

22 avr

importance des signatures formelles sur les projets

En lisant l’article de Tim In gram-Smith sur PMHUT, j’ai essayé de comparer son vécu avec ses clients externes à mon expérience ur des projets informatiques internes à l’entreprise.

En fait, je dois reconnaître que notre position de collègues entre informaticiens et représentants métiers/business en lieu et place d’une relation client-fournisseur entre deux entreprises change quelque peu la donne mais pas autant que l’on pourrait le penser de prime abord.

En fait, les projets les plus réussis sur lesquels j’ai travaillé avaient des objectifs très clairs, documentés par écrit et un engagement fort du management.

sign offCe fut par exemple le cas lors de l’implémentation d’un progiciel de gestion intégré (Enterprise Resource Planning – ERP) au niveau mondial en 18 mois dans une grande multinationale. Le directeur du programme (dont je dirigeais le PMO) s’est assuré de cette clarté d’objectifs en les documentant et les faisant signer par le comité exécutif du programme et par son sponsor, le directeur financier de l’entreprise.

Cette initialisation du programme fut critique à notre réussite: Elle nous a donné un périmètre clair, des objectifs agréés et mesurables, des moyens définis et approuvés tant pour les ressources internes qu’externes, et des engagements forts de support au changement du top management.

Ce programme de déploiement d’ERP comportait également un large volet optimisation et unification des processus et réorganisations des fonctions centrales, régionales et pays de la finance. Tous les processus financiers redéfinis par l’équipe projet furent signés manuellement par les responsables métiers de l’entreprise (contrôleurs financiers des pays, des régions et centraux; responsables de la comptabilité, de la facturation, des achats…).

Une signature manuelle reflète à mon avis un engagement bien plus fort qu’un courrier électronique d’approbation.

Businesswoman Reading a WhitepaperPersonnellement, avant de signer manuellement un document, je le lis de manière très attentive. Il arrive même souvent que je demande une vérification à un expert du domaine en question de mon équipe pour les aspects techniques ou business. Mon sentiment reste qu’une signature manuelle a plus de valeur qu’une approbation électronique. Je réalise qu’il s’agit très certainement d’une perception erronée puisque de nos jours de simples SMS peuvent être pris en compte devant un tribunal, mais je ne suis certainement pas le seul à être victime de cette perception. Et, la perception EST la réalité à laquelle le chef de projet doit souvent faire face. Cela changera-t-il avec les générations Y ou millénium nées avec Internet et les communications mobiles ?

Comme Tim le mentionne dans son article, les tentations sont nombreuses de démarrer sans signatures formelles.

Nous les expérimentons également sur les projets internes, notamment l’excuse des délais imposés, la pression du management et des collègues, et la peur de laisser des employés inoccupés:

1. les délais imposés sont toujours de mauvaises raisons !

deadline“Toute proposition de solution qui ne peut être prête pour le 1er janvier ne nous intéresse pas!”. J’ai été témoin, et même partie prenante je le reconnais maintenant, de nombreuses décisions de choix de projets ou de solutions techniques basées sur des critères de disponibilité prévisionnelle. Certains composants auraient mieux répondu aux besoins business mais semblaient prendre trop de temps. En informatique, un exemple typique est d’essayer à tout prix de réutiliser une application développée dans un service pour un but précis dans d’autres circonstances et pour d’autres objectifs. “Cette application marche bien en Europe, il n’y a pas de raison pour qu’elle ne marche pas en Asie où nous commercialisation les mêmes produits…”. En effet, cela paraît logique et séduisant: moins de développement et de tests, disponibilité des compétences, rapidité d’obtention de la solution…

Hélas, le temps d’adaptation de la solution au nouveau contexte est trop souvent sous estimé et, de plus, l’adéquation de la solution aux besoins de ses futurs utilisateurs largement surestimée avec une prise en compte limitée des contextes, marchés, et cultures différentes. Il en résulte souvent une insatisfaction des nouveaux utilisateurs, ou des délais de mise en service proches au final des autres solutions qui auraient pu être choisies sans ce focus initial sur les délais.

2. la pression du management et des collègues même bien intentionnée est souvent mauvaise conseillère.

douleurLà aussi, même si ces pressions partent de convictions sincères des personnes de supporter la “bonne solution”, elles sont souvent le résultat de vues partielles de la situation ou des objectifs complets du projet.

Elles sont aussi teintées de considérations plus terre à terre de disponibilité des compétences requises pour chaque solution, de luttes de pouvoir interne, de désir de développement de nouvelles compétences dans son département, d’affectation des ressources au niveau global du portefeuille de projets ou de l’entreprise.

On ne peut les ignorer, mais elles ne doivent pas obscurcir notre vision et nous éloigner des critères agréés de choix de la meilleure solution pour votre projet.

3. la volonté d’utiliser à tout prix les ressources disponibles.
Image courtesy of suphakit73 / FreeDigitalPhotos.net

Image courtesy of suphakit73 / FreeDigitalPhotos.net

Autre élément que Tim mentionne dans son article et qui est très important: Le sentiment de devoir à tout prix utiliser les ressources disponibles et non affectées qui est très fort et assez légitime du point de vue du management de l’entreprise.

Mais, du point de vue du projet:

  • Ces ressources ont-elles les compétences requises?
  • Sinon, combien de temps faudra-t-il passer à les former et cela est-il même faisable?
  • Si elles sont disponibles et ont les compétences, est-ce une raison suffisante pour démarrer sans approbation formelle du projet?
SMPP

Partenaire de DantotsuPM

Mon expérience est mitigée.

En fait, si une confiance réciproque et forte existe entre business et informatique, on peut démarrer des projets de tailles réduites, des prototypages, ou du développement incrémental en boucle rapide sans signature formelle.

Mais, sur de gros projets informatiques, cela vaut le coup de sécuriser les approbations de toutes les parties avant de démarrer sous peine de devoir défaire puis refaire (si l’on en a encore les moyens) ce qui aurait été produit avec un manque d’alignement sur les objectifs.

Comme le disait l’un des consultants senior avec lequel j’ai eu la chance de travailler :

“Si vous ne prenez pas le temps maintenant de bien faire les choses,

dites moi quand vous prendrez le temps de les refaire !

Car, n’ayez aucun doute, il vous faudra les refaire.”

Management de Portefeuille de Projets et Agile : Réunir les Deux Mondes pour le Meilleur – par Vincent Coustillac

14 avr
Vincent Coustillac

Vincent Coustillac

Cet article est proposé par Vincent Coustillac, consultant Net’sFive – réseau d’experts en Management de Projets.

A propos du défi causé par l’intégration d’une méthode Agile dans le cadre du Management de Portefeuille de Projet (PPM), et de comment donner la visibilité nécessaire à la Direction d’entreprise sans perturber la culture et les pratiques des équipes Agile.

Cet article présente un ‘White Paper’ publié par Daptiv, – société américaine spécialisée dans les systèmes de management de portefeuille de projets (http://www.daptiv.com) qui peut être téléchargé dans son intégralité (en version originale anglaise) depuis ce lien.

SMPP

Partenaire de DantotsuPM

Ce ‘White Paper’ a particulièrement attiré notre attention car il montre comment, malgré les idées fausses associées aux méthodes Agile, les projets exécutés dans ce mode peuvent très bien être intégrés dans un management de portefeuille de projets. Cela bien-sûr en tenant compte des caractéristiques propres à la culture et aux pratiques des équipes Agile, et des exigences générées par leur intégration dans un portefeuille de projets.

Le ‘White Paper’ commence par une introduction du modèle Agile et ce qui le distingue du modèle de gestion de projet traditionnel, pour ensuite aborder le cœur du sujet.

Le défi : Intégrer les processus PPM et Agile

De nombreux portefeuilles de projets comprennent maintenant un mélange de types et de méthodologies projet, tels que les projets traditionnels en cascade, des projets en mode Agile, des projets Six Sigma et des projets «Stage-Gate» au cycle de vie déterminé pour le développement de nouveaux produits.

Cependant, même avec cette volonté d’adopter une méthode Agile, l’intégration de projets Agile dans un cadre PPM s’est avérée difficile pour de nombreuses organisations.

Les 3 Idées  Fausses sur l’association PPM et Agile

Le mouvement Agile a eu une influence significative sur les bonnes pratiques en gestion de projet. Cependant, quelques principes Agile tels que l’acceptation du changement, la planification "juste-à-temps", et la suppression de la prise de décision hiérarchique ont conduit à des idées fausses sur la compatibilité des projets en mode Agile avec les processus PPM.

Voici trois idées fausses communes (et pourquoi elles sont fausses) sur les principes Agile qui ont compromis l’intégration des projets Agile dans un portefeuille de projets.

Idée Fausse #1 : Les Projets Agile ne Donnent pas une Visibilité Suffisante à la Direction

Une grande partie de la popularité de la méthode Agile réside dans la croyance que les équipes doivent être habilitées à prendre des décisions business plutôt que de compter sur les parties prenantes dirigeantes pour approbation. Responsabiliser une équipe, cependant, ne signifie pas que des rapports d’avancement ne doivent pas être fournis en temps opportun à l’équipe dirigeante. La difficulté à laquelle les équipes sont confrontées est la nécessité de fournir des rapports d’avancement dont les dirigeants ont besoin, mais qui sont peu compatibles avec les pratiques Agile. Les dirigeants doivent apprendre à interpréter le statut de projet d’une équipe Agile plutôt que d’imposer des exigences de rapports d’avancement qui ne sont pas compatibles avec les pratiques Agile.

Idée Fausse #2 : Les Projets Agile n’ont pas de «Dates de Fin Prévues» Fiables

Bien que les équipes Agile évitent de fournir des dates de livraison garanties (étant donné le cône d’incertitude autour d’un projet), c’est une erreur de penser qu’un projet Agile ne puisse pas donner une date de fin prévue. Il est vrai que les équipes Agile fournissent des estimations «juste-à-temps» pour chacune des itérations et se concentrent sur la fourniture progressive de la valeur commerciale, cependant  un plan de réalisation et de livraison global doit pouvoir faire l’objet d’une estimation de haut niveau. L’utilisation d’«epics» (grandes «stories ») et «themes» (groupes de «stories») permet d’estimer le travail dont il convient de détailler le contenu.

Idée Fausse #3 : Les Pratiques Agile et Traditionnelles ne sont pas Compatibles

Certaines pratiques Agile ont des différences fondamentales avec des pratiques traditionnelles de gestion de projet. Cependant, il n’est pas vrai que les deux types de pratiques ne peuvent pas être combinés pour créer un cadre de gestion de projet efficace. Par exemple, les pratiques Agile ne couvrent généralement pas la consommation du projet ou le processus d’initiation du projet, et les pratiques traditionnelles concernant les coûts du projet, la communication et la gestion des risques sont souvent plus matures que les pratiques Agile correspondantes.

Intégration d’une méthodologie Agile dans un cadre PPM

Daptiv PPM 1L’intégration d’une méthodologie de projet Agile dans un cadre PPM n’est pas différente de l’intégration d’une méthodologie de projet plus traditionnel, à quatre exceptions près:

1. Les équipes Agile fonctionnent manifestement mieux lorsque les dirigeants et les chefs de projet n’étouffent pas les processus Agile. Imposer des revues inutiles des parties prenantes, des points de contrôle et des exigences de saisie de données sur un projet Agile réduira considérablement l’efficacité de l’équipe. Bien sûr, si des décisions importantes doivent être prises avec la participation de la Direction ou si un projet Agile a des dépendances avec d’autres projets, des réunions avec les parties prenantes seront nécessaires, mais celles-ci doivent être l’exception et non la règle.

2. Les projets Agile mesurent la progression des «story points» terminés et la valeur commerciale livrée. C’est un moyen fondamentalement différent de suivre les progrès réalisés plutôt que d’utiliser un plan des tâches et la mesure des heures consommées sur les tâches accomplies. En outre, le chef de projet assigne des responsables de tâches dans un projet traditionnel, tandis que les équipes Agile s’auto-organisent, de sorte que les tâches sont réaffectées à tout moment par l’équipe pour assurer une livraison optimale du projet. Cette différence exige que les mesures de "la santé de projet" et du "pourcentage d’avancement" soient établies différemment des projets traditionnellement basés sur les temps passés par tâche.

3. Du fait que les affectations de tâches au sein d’une équipe Agile sont dynamiques, il n’est pas recommandé d’attribuer des ressources à temps partiel dans une équipe Agile, car cela brise le modèle d’auto-organisation. Au lieu de cela, il est préférable de traiter les équipes Agile comme un tout et affecter des ressources à plein temps (à l’exception des ressources telles que les architectes, les administrateurs de bases de données, qui sont généralement réparties sur plusieurs projets).

4. Enfin, les revues régulières des projets Agile sont plus orientées sur «l’état du produit» plutôt que sur l’atteinte de jalons prédéterminés ou la livraison de la documentation du projet. Les revues doivent être adaptées au type de projet afin de s’assurer qu’elles apportent une valeur pour l’équipe.

Des mesures communes aux différents types de projets

Afin de les intégrer dans un cadre PPM, les cinq paramètres communs qui permettront aux dirigeants d’obtenir une visibilité de l’état des projets, quel que soit le mode d’exécution, sont les suivants :

  • La date de fin prévue : "La date de fin planifiée" est l’estimation faite lors de la création du projet pour la date de livraison prévue, alors que "la date de fin prévue" est l’estimation de la date de fin du projet réactualisée en fonction des données actuelles. Pour un projet traditionnel, ces dates sont basées sur le planning des tâches et le chemin critique du projet. Pour un projet Agile, elles sont basées sur le plan de livraison. Étant donné qu’un «cône d’incertitude» existe indépendamment de la méthodologie de projet, l’exactitude des dates de fin prévues devrait être comparable pour les deux types de projets traditionnels et Agile.
  • Le pourcentage d’avancement : Pour un projet traditionnel il est calculé en additionnant les heures des tâches accomplies et en divisant par le nombre d’heures total des tâches du projet. En revanche, le progrès d’un projet Agile est mesuré par les «story points» livrés, le pourcentage d’avancement est alors mesuré par rapport au nombre total de «story points» prévu du projet.
  • Les modifications du contenu : Pour les projets traditionnels, cela est représenté par le nombre de demandes de changement. Pour un projet Agile, cela est mesuré par la variation en «story points» totaux au fil du temps.
  • Coûts réels et budgétés : Ces mesures doivent être rapportées pour les deux types de projets traditionnels et Agile. Alors que sur les projets traditionnels ces mesures peuvent se faire sur la base des tâches et des temps passés, il n’est pas approprié de demander à une équipe Agile de suivre les temps au niveau des tâches pour calculer les coûts des ressources. Au lieu de cela, les ressources doivent être dédiées à une équipe Agile et les coûts calculés en conséquence.
  • Le statut du projet : Le statut du projet est une mesure qui résume si un projet est «sur la bonne voie", "a besoin d’attention" ou est "en difficulté". Son évaluation varie selon l’organisation et est calculée en utilisant la logique conditionnelle basée sur les quatre mesures ci-dessus, ainsi que d’autres données telles que les questions en suspens.

La fourniture de ces mesures dans un tableau de bord d’un système PPM permet aux dirigeants d’identifier rapidement les projets qui nécessitent une attention particulière ou une intervention, quelle que soit la méthodologie utilisée pour son exécution.

Le ‘White Paper’ se termine par deux points essentiels

La calibration des mesures des différents types de projets dans les programmes et les portefeuilles, ainsi que la nécessité de créer une source unique de référencesingle source of truth – pour la Direction.

-=-=-=-=-=-

NetsFive LogoNet’sFive accompagne les entreprises pour favoriser leur développement par la maîtrise des projets à tous les niveaux de l’entreprise : depuis la conduite des projets individuellement, le contrôle global des projets de l’entreprise, l’optimisation des ressources et jusqu’au management du portefeuille des projets pour une gestion priorisée des projets alignés avec la stratégie de l’entreprise.

about the striking importance of signatures in projects

8 avr

When I read Tim Ingram-Smith’s post on PMHUT, I tried to match his experience gained on external customers’ projects with mine in internal information technology projects.

In fact, the colleague to colleague relationships between computer specialists and business users within the same company instead of a customer-supplier relationship between two companies does change the situation but may be  not as much as one could think at first sight.

The most successful programmes on which I worked had very clear, documented written objectives and strong commitment of the top management.

It was for example the case during the Implementation of an Enterprise Resource Planning (ERP) software package globally in 18 months at a large multinational company. The director of the program (for which I ran the PMO) made sure of the clarity of the objectives by documenting them and having them signed off by the executive committee of the program and by his sponsor, the Chief Financial Officer of the company.

This initialization of the program was critical to our success:
  • It provided a clear scope,
  • agreed and measurable objectives,
  • defined and endorsed means for internal and external resources, and
  • commitments to assistance to proper change management by key executives.

This ERP deployment program also contained a wide ranging organizational optimization aspect and standardization of processes accompanied by functional reshaping of the finance departments. All financial processes which were redefined by the team project were manually signed by the people in charge of these operational functions in the company (countries and regions financial controllers; responsible for accounts department, for the invoicing, the purchases…).

A manual signature reflects in my opinion a much stronger commitment than an email approval very much the same as paying in cash is a more cautious/conscious spend than an electronic payment.

Personally, before signing manually a document, I read it in a very attentive manner. I may even ask a domain expert on the team to verify ome of its technical contents. Therefore, my personal feeling remains that a manual signature has more value than an electronic one. I realize that it may be an incorrect perception since nowadays a simple SMS can be used as proof in front of a court, but I am certainly not the only one to be a victim of this perception. An in Project Management, perception is often king. Will it change with the generation Y that was born with Internet and mobile communications? What is your own personal opinion?

As Tim mentions in his article, the temptations are numerous to start without formal sign-off.

We also experience these on internal projects, notably the excuse of critical due dates, pressure from management and colleagues, and fear to leave some employees idle:

1. Compulsory timeframes: always a bad reason!
Image courtesy of photostock / FreeDigitalPhotos.net

Image courtesy of photostock / FreeDigitalPhotos.net

“Any solution proposal which cannot be ready by January 1st is of no interest to us!”. I witnessed and I admit I was also a stakeholder of numerous decisions where the choice of solutions was based mainly on the projected delivery date. Often, other components would have better met the needs businesses but seemed to take too long to build.

In computing, a typical example is to try by all means to reuse an application developed in a group for a precise purpose in other circumstances and for other objectives. “This application works perfectly in Europe, there is no reason why it shouldn’t work in Asia where we sell the same products and services”.

Indeed, it appears logical and attractive: less development and testing, skills availability, speed to get the solution …

Regrettably, the time required to tailor the solution to the new context is very often vastly under-estimated and, furthermore, the adequacy of the solution to the needs of its future users widely over-estimated with a limited consideration of context, work practices, and cultural differences. It often results in a high dissatisfaction of the new users and, at the end of the day, a launch date close to other solutions we could have selected if we stopped the sole focus on projected delivery time.

2. Pressure from management and colleagues.

Even when these pressures come from sincere convictions of the persons who support their "best solution", they often result from a  partial understanding of the situation and of the full objectives of the project.

They are also tinged with considerations more down-to-earth such as availability of the skills required for each solution, internal power play, desire to develop new skills in a department, allocation of resources at the level of the projects portfolio.

We cannot ignore them, but they do shouldn’t biases our vision and take us away from agreed selection criteria for the best solution for our project.

3. Available resources.
Image courtesy of graur razvan ionut / FreeDigitalPhotos.net

Image courtesy of graur razvan ionut / FreeDigitalPhotos.net

Another element than Tim mentions in his article and which is very important: the imperious desire to use available and unoccupied resources is very strong and somewhat justifiable from the point of view of the management of the company.

But, from the point of view of the project:

  • Do these resources have the required skills?
  • If not, how long will it take to develop them and is it even feasible?
  • If they are available and have the skills, is it a sufficient reason to start without formal approval of the project?
My experience here is mixed.

In fact, if a strong mutual trust exists between business and IT, we can start projects of reasonable size, prototypes, or incremental development without formal signature in an "Agile" development approach.

But, on any big IT project, it is worth securing the approvals of all parties before starting (in Agile or more traditional approaches).

Otherwise, we run the risk of having to undo and then redo (if we still can do so) what could have been done first shot with a better alignment of the project on its objectives.

One of the senior consultants I had the chance to work with used to say:

“If you do not take the time to do it right the first time, then tell me when you will take time to redo it!

Because, you shall have no doubt: it will be necessary to redo it.”

Pour mener à bien vos projets, fixez des priorités par Jeff Ball

7 avr
Jeff Ball

Jeff Ball

Si vous souhaitez mener à bien toutes vos tâches, fixez des priorités.

Toutes les tâches n’ont pas la même importance. Dans ce monde surchargé, si vous n’établissez pas de priorités, vous ne mènerez pas à bien les bonnes tâches.

Cette simple vérité s’applique à tous les niveaux. Au niveau le plus bas, elle s’applique à votre productivité personnelle. À un niveau plus général, elle s’applique à vos projets, votre équipe ou votre entreprise. Si vous n’établissez pas de priorités, vous ne pourrez pas tout gérer et mener à bien l’essentiel. Vous serez distrait en chemin par une multitude de détails et de choses secondaires.

PRODUCTIVITÉ PERSONNELLE

QRP International France

Partenaire de DantotsuPM

GTD (Getting Things Done, s’organiser pour réussir) est la méthode du moment. David Allen, un gourou américain, a développé cette méthode innovante, qui fut un succès commercial pour lui, mais un désastre pour la productivité personnelle de beaucoup de gens, car elle provoqua un raz de marée d’offres GTD – il existe des centaines d’applications pour Smartphone, Mac et PC, de livres, de sites internet et de vidéos basés sur le travail de David Allen.

Lesquelles peuvent toutes vous faire tomber dans le même piège: vous vous retrouvez avec une liste de tâches à n’en plus finir, sans ordre de priorité, dont vous essaierez de vous acquitter une par une.

Accomplirez-vous plus de tâches pour autant? Pour beaucoup de gens, la méthode GTD n’améliore pas la productivité personnelle; elle provoque le désordre.

C’est comme un tas de compost – un amas désordonné où se mélangent les tâches récentes avec les anciennes; et les plus urgentes avec les plus insignifiantes.

Il existe de meilleures façons de travailler, et de meilleures applications. Une des premières applications était incluse, il y a dix ans, avec le Palm Pilot, avant que David Allen n’écrive son livre. Le Palm était un prédécesseur du Smartphone, et il dut une partie de son succès à son excellente application “ToDo”, qui établissait un ordre de priorité entre les tâches de manière très simple (et, bien sûr, par catégorie également). Ainsi, on savait ce qui était important. Aujourd’hui, on trouve quelques bonnes alternatives au GTD, telles que l’application 2Do, qui permet de classer les tâches selon 5 ordres de priorités différents (Star-High-Medium-Low-None). Ces applications fonctionnent, elles aident réellement à mener à bien les bonnes tâches. Grâce à elles, on sait ce qui est important, même lorsqu’on a des centaines de choses à faire.

ÉTABLIR DES PRIORITÉS DANS UN PROJET POUR RESPECTER LES DÉLAIS

Agile Project Management LogoDans le monde du travail, certaines méthodes de projet établissent les priorités de façon à respecter les objectifs et les délais. La méthode AgilePM, basée sur le DSDM Atern, une variante d’Agile, utilise la priorisation MoSCoW. MoSCoW est un acronyme qui se traduit par “Doit être fait”, “Devrait être fait”, “Pourrait être fait”, “Ne sera pas fait” ("Must Have", "Should Have", "Could Have", "Won’t Have"). En utilisant la priorisation MoSCoW, vous priorisez vos objectifs (fonctions ou besoins) aussi bien au niveau du projet dans son ensemble que fraction par fraction. C’est une technique puissante, qui aide vraiment à accomplir les tâches les plus essentielles, et – très important – à garantir le respect des délais. (Il s’agit d’une technique Agile applicable à des projets non Agile, en se servant de méthodes Waterfall ou de méthodes comme PRINCE2).

GESTION DE PORTEFEUILLE DE PROJETS

moplogoD’un point de vue plus général, il est également important d’établir des priorités. Si vous gérez plusieurs projets ou programmes, vous possédez un portefeuille de projets que vous avez tout intérêt à prioriser avec soin et discernement, afin de remplir vos objectifs stratégiques. Si vous n’établissez pas de priorités, vous serez surchargé de travail, mais vous n’atteindrez aucun but.

P3OLa meilleure façon d’aborder le problème est d’établir des priorités en combinant l’attrait et la faisabilité de chaque projet ou programme.

L’attrait devra se baser sur plusieurs critères, comme l’adéquation avec votre stratégie de haut niveau et le ROI (retour sur investissement) attendu

La faisabilité, typiquement, se basera sur le risque de réalisation (probabilité de réussite)

Les guides spécialisés tels que MoP (Management of Portfolios, gestion de portefeuille) et le P3O (Project, Programme and Portfolio Offices; Portefeuille, Programmes et Projets) indiquent la marche à suivre. Ils conseillent de commencer par s’entendre sur la Gestion de Portefeuille de Projets. Une fois arrivé à un accord sur ce point, vous pouvez l’utiliser pour évaluer votre portefeuille actuel ainsi que la “demande” (ce flux d’idées et de requêtes nouvelles qui pourraient venir s’ajouter à votre portefeuille). Cette méthode s’avère être la meilleure. Elle fonctionne.

SMPP

Partenaire de DantotsuPM

Donc, que vous ayez besoin de mener à bien des tâches à un niveau personnel, dans le cadre d’un projet ou d’un portefeuille de projets, vous devez mettre en place des priorités. Sinon, il est probable que vous vous égariez. Si vous suivez cette méthode, vous pourrez réellement mener à terme les BONNES tâches.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

quand est-il temps de créer un PMO ?

3 avr

When is it Time to Create a Project Management Office?

http://www.projectmanager.com/create-a-project-management-office.php

travail d'équipeUn Bureau de Management de Projet (Project Management Office : PMO) est un service ou un groupe de personnes qui définit et maintient les standards liés au management de projet, dans une organisation. En sus de définir et maintenir ces standards, un PMO est (ce qui est plus important) responsable de l’exécution et de la mise en œuvre réussies des projets qui tombent sous sa juridiction.

Il y a un certain nombre d’avantages à implémenter une telle structure dans une société. Mais un PMO n’est pas quelque chose qui est typiquement présent dès le départ, particulièrement dans une petite société. L’article suivant discutera de certains des bénéfices du PMO ainsi que de certains des signaux suggérant qu’il pourrait être temps d’établir un PMO.

Trois bénéfices du PMO

Il y a un certain nombre d’avantages que gagne une société dès qu’elle implémente un bureau de management de projet à l’échelle de l’entreprise :

1. Créer et implémenter des systèmes et processus cohérents

processUn des bénéfices majeurs des PMOs est leur capacité à créer et implémenter des systèmes et des processus cohérents. Les sociétés réussiront pour certaines raisons. Elles ont un super produit, elles ont un excellent personnel commercial, elles sont novatrices, ou une combinaison d’autres facteurs les mènera à leurs succès. Avec ces succès vient la croissance et avec la croissance viennent certaines douleurs qui s’amplifient.

Il y a une certaine mentalité qui se met en place quand une société grandit exponentiellement. J’ai une fois entendu un collègue d’une société en forte croissance dire que "n’importe quelle décision qui fait avancer la société est la bonne décision". L’esprit de ce qu’il disait était que vous ne pouvez pas prendre du temps pour ralentir dans une société en forte croissance ni analyser méthodiquement chaque solution possible quand une décision doit être prise. Les gens doivent plutôt prendre des décisions sur le champ et en temps réel pour garder les choses en mouvement.

Cela marche bien dans la théorie. Cependant, à long terme, ceci introduit des façons très contradictoires, imprévisibles et parfois incertaines de réaliser le travail, quel que puisse être ce travail. Une fois qu’une société a atteint ce niveau de confusion, c’est un grand soulagement pour ceux qui sont impactés qu’un tiers objectif (aussi connu sous le nom de PMO) entre en jeu et aplanisse les choses.

Les membres du PMO identifieront les systèmes et les processus qui marchent, se débarrasseront de ceux qui ne fonctionnent pas et boucheront les trous.

2. Une source objective de vérité

assomptionUn autre avantage qui vient une fois qu’un PMO est implémenté est qu’il y a un endroit objectif où trouver la vérité. Qu’est-ce que ça signifie ? S’il est configuré correctement, un PMO n’aura pas de ressources lui rapportant directement (autre que des chefs de projet et peut-être quelques analystes business). En tant que tel, il n’a rien à cacher ou dissimuler lorsqu’il s’agit de faire un rapport sur le statut du projet. Si un service exécute ses propres projets, il peut ne pas être tout à fait objectif dans son rapport sur le vrai état d’avancement.

Nous ne parlons pas des gens qui mentiraient délibérément, mais plutôt fournissant leur "version de la vérité". Par exemple, un service peut savoir qu’il a manqué la date d’un livrable. Mais, il sait aussi que, d’ici la réunion de statut suivante, ils pourront rattraper le retard et donc ne pas vouloir rapporter que c’est un risque potentiel. Puis, une urgence arrive, ce livrable n’est jamais fini et maintenant le projet est en mode crise.

Un PMO fournit la visibilité dans une telle situation et identifie les conséquences négatives. Si le produit n’était pas fini le jour prévu et une date de fin clairement identifiée, ceci aurait été rapporté comme un risque potentiel. Ceci aurait donné au sponsor de projet ou au management de la société la capacité de faire quelque chose à ce propos et éviter qu’il devienne hors contrôle.

Le Président d’une société de développement logiciel m’a dit une fois qu’il utilise la personne qui fait tourner son PMO comme le baromètre indiquant dans quelle mesure les choses se passent (bien ou mal) dans la société. "S’il est un peu inconfortable, je sais que je dois aller dans les détails et voir où je dois aider. S’il est calme, cool et détendu, alors je vais déjeuner. Je sais que tout va bien."

3. Introduit des économies d’échelle
Image courtesy of suphakit73 / FreeDigitalPhotos.net

Image courtesy of suphakit73 / FreeDigitalPhotos.net

Un PMO réduit aussi ou élimine des duplications d’efforts et du gaspillage de ressources. Si personne n’a de vue d’ensemble des activités dans une société, des projets et initiatives semblables peuvent commencer à apparaître en de multiples emplacements alors qu’il n’y en a en fait aucun besoin. Une solution suffirait, mais les personnes qui travaillent sur les autres solutions ne sont pas conscientes qu’il y a déjà une solution en construction. Un PMO peut stopper cette duplication d’efforts en employant un logiciel de management de projet  pour coordonner à travers divers services, s’assurer que le travail est fait…une seule fois.

Ce sont seulement certains des bénéfices dont vous vous rendrez compte une fois qu’un PMO sera implémenté avec succès. Mais, comment savoir qu’il est temps de prendre ce chemin ?

Quand est-il temps d’avoir un PMO ?

whenIl n’y a aucune taille, revenu, ou configuration particulière d’une société qui indiquerait qu’il est temps de commencer un PMO. Cependant, les symptômes suivants peuvent être des signes avant-coureurs.

1. Les produits ne sortent pas

En raison du succès de la société et de ce que vous offrez, il y a des encombrements et des ralentissements qui créent des goulots d’étranglement dans toute la société. Ceci ralentit énormément le travail, causant du travail additionnel et introduisant bien des problèmes ultérieurs qui se manifestent à cause de ce type de mauvais management.

2. Il semble que chaque projet soit une Première

Innovation Road Sign with dramatic clouds and sky.Bien que vous puissiez avoir fait maintes fois un type particulier de projet (par exemple, votre société peut créer des sites Web qui exigent une certaine quantité de personnalisation pour le client), il semble que ceci est la première fois que vous ayez jamais fait ce type de projet. Les personnes se bousculent, on ne pose pas les questions nécessaires avant qu’il ne soit trop tard, ou les produits restent posés sur une étagère quelque part, n’obtenant pas de débouchés commerciaux, tandis que le service qui devrait faire le travail reste inoccupé. Si cela nécessite une suite d’erreurs pour sortir un projet, il pourrait être temps de mettre en place un PMO.

3. Il n’y a pas un seul groupe qui sache ce qui se passe à travers la Société

team work / complémentaritéTout le monde a des éléments selon sa position, ou ils peuvent avoir leur propre vue très myope du monde…mais personne ne sait comment tout est relié… et ceci commence à créer des problèmes. Les produits que l’on passe d’un service au suivant ne peuvent pas être configurés de façon appropriée, ou il manque les éléments clés par rapport à ce qui était convenu à l’origine. Il pourrait être temps de mettre en place un bureau de management de projets pour fournir cette vue d’ensemble.

Comme précédemment mentionné, un PMO est quelque chose qui sera typiquement introduit dans une société une fois qu’elle a atteint une certaine taille. Cependant, les principes d’un bureau de management de projet peuvent être appliqués dans les sociétés de n’importe quelle taille et leur permettre un bon en avant dans la création des systèmes et processus dont elles ont besoin pour exécuter avec succès les projets lors de leur croissance.

SMPP

Partenaire de DantotsuPM

Si vous cherchez une solution logicielle de PMO qui grandira avec vous et votre société, que vous ayez un chef de projet ou des douzaines de chefs de projet, ProjectManager.com vous aidera à manager les équipes, suivre les résultats, collaborer en ligne et rapporter l’avancement intelligemment.

11 Avril – Saguenay – L’implantation d’un bureau de projets : Un défi à relever

31 mar

Déjeuner Conférence 1,5 PDUs. Accueil dès 7h00 pour une conférence de 7h30 à 9h00

Un événement du PMI Levis-Québec animé par Nicole Parizeau, Conseillère en gestion de projet, R3D Conseil inc.

Nicole Parizeau

Nicole Parizeau

Le défi des organisations est d’assurer le succès de leurs projets d’investissement. La rigueur dans la réalisation des projets, l’application des meilleures pratiques de l’industrie et la gouvernance dans le choix des projets d’investissement et leur suivi sont des facteurs qui augmentent les chances de réussir les projets. Un bureau de projets permet à l’organisation de se concentrer à l’atteinte de ces objectifs.

SMPP

Partenaire de DantotsuPM

8 avril – Genève – Le Piano Coach – SMP2 : Système de Management du Portefeuille de Projets

26 mar

Par Erick Athier, le Mardi 8 avril de 18h30 à 20h30

L’entreprise est un ensemble de stratégies et de ressources que les directions gèrent au quotidien autour de deux enjeux majeurs, mais néanmoins ‘concurrents’ : Produire de la valeur et augmenter de manière continue la capacité à produire de la valeur.

SMP2La production de valeur, priorité absolue de l’organisation, se réalise à travers ses opérations récurrentes, le plus souvent largement maîtrisées.

En revanche, et quel que soit son niveau de performance opérationnel, l’entreprise doit en permanence, penser et agir pour se transformer: innover dans ses produits ou services, se mettre en conformité, traquer la non performance, mettre en place de nouveaux outils, développer les compétences…

Cette capacité à se transformer se réalise concrètement à travers des projets. C’est pour vous accompagner dans la maîtrise des processus spécifiques à la création de valeur par les projets qu’en partenariat, IQar et BUREAU VERITAS CERTIFICATION, ont développé un nouveau référentiel de labellisation : SMPP.

Lors de cette conférence vous ferez un état des lieux des référentiels / modèles de maturité existants en la matière. Vous capitaliserez sur les bénéfices à les déployer et vous découvrirez la démarche, les outils et la communauté spécifiques au référentiel SMPP.

SMPP

Partenaire de DantotsuPM

March 28 – Webinar (PMI) – Challenges faced by Program Managers in Global Environments

20 mar

PMI’s International Development Community of Practice with Yaravi Cardoze

28 March 2014 • 19:00 CET/France


Yaravi CardozeProgram Management has many challenges by nature. Driving Programs in global environments adds additional components to this interesting role.

As global economies are changing, new opportunities for emerging markets like Latin America are finding their space in the global market place, and projects and programs are part of it.

This webinar is based on experiencing program management challenges in today’s global world.

The webinar will share and discuss points of view about the main challenges of the program manager role in global environments. Best Practices on what worked and what didn’t will be shared with participants. This webinar will add to their current skills, and raise interest for deep dive on global opportunities.

SMPP

Partenaire de DantotsuPM

June 9-10 – London – Gartner PPM & IT Governance Summit

12 mar

gartner PPM Summit 2014

The Gartner PPM & IT Governance Summit 2014 is the premier gathering of program and portfolio management executives focused on improving how organizations select, implement and manage IT initiatives and services.

SMPP

Partenaire de DantotsuPM

Gain new methods of prioritization, resource optimization and governance to address competing strategic goals, as well as how to adapt programs with an eye toward shifting risks and ongoing business case validity.

Visit the web site

Visit the web site

Suivre

Recevez les nouvelles publications par mail.

Joignez-vous à 505 followers

%d bloggers like this: