Archives de Tag: change management

gagner une bataille mais perdre la guerre

16 mai

Winning the Battle but Losing the War

http://philipdiab.com/2011/09/winning-the-battle-but-losing-the-war/

par Philip R. Diab

Il y a quelques semaines nous avions un problème avec une livraison à domicile d’un restaurant. Il s’est avéré que la personne ayant pris la commande avait mal entendu et n’avait pas envoyé le bon plat à notre maison. Quand nous avons appelé le restaurant et avons discuté avec le Responsable du Service Client, il nous a informé qu’il avait écouté l’enregistrement de la commande et décidé que son collaborateur n’avait pas mal entendu la commande, mais plutôt que nous ne l’avions pas exprimé correctement. Il a non seulement refusé de rectifier la situation, il a au lieu de cela dit que c’était notre faute.

La chose étonnante pour moi est que c’est un établissement que nous utilisons régulièrement et il était stupéfiant que ce manager ne l’ait pas pris en considération. Ainsi, une erreur qui lui aurait très peu coûté n’a pas été réparée. Au lieu de cela cet établissement a perdu un habitué et l’argent dépensé dans cet établissement sur une base récurrente.

Le point est ici évident, Le Responsable Service Client a pensé qu’il agissait convenablement et dans le meilleur intérêt du restaurant. Il a effectivement gagné la bataille. Mais en nous importunant et nous faisant passer de clients à « non-clients », il a en fait perdu la guerre. Il a non seulement perdu un revenu futur mais il s’est retrouvé à devoir gérer une mauvaise presse quand nous avons informé notre réseau d’amis et associés de notre infortune.

Dans le management de projet il y a tout un ensemble de problèmes qui exigent notre intervention. On s’attend à ce que les chefs de projet soient orientés sur les détails pour qu’ils puissent indiquer d’où vient la faute sur n’importe quel problème donné afin d’y remédier convenablement. Le défi consiste cependant à ne pas oublier qu’il y a des impasses. Certes, nous pouvons établir que le client ou un certain groupe de parties prenantes ont eu tort. En outre, nous pourrions même faire payer ce groupe pour des changements de contenu, de coûts, ou de délais. Cela pourrait nous aider à sauver la face à court terme. Cependant, dans le long terme l’histoire est toute autre.

Il y a longtemps, un mentor m’a dit que quand vous opérez comme consultant la meilleure chose que vous puissiez espérer pour vous-même si vous vous disputez avec un client est de vous faire débarquer du projet. Même si cela peut être un peu extrême, je préconiserais certainement que pour protéger nos droits et ceux de nos organisations, nous devons garder une vue stratégique du résultat potentiel de ces types de problèmes.

tirer sur la cordeParfois nous pourrions trouver nécessaire de prendre à notre charge le faible coût d’un changement de contenu, bien que le client n’ait pas fourni de besoins appropriés et soit clairement en tort, pour s’assurer que la relation reste positive. Une approche équilibrée doit être imaginée par les chefs de projet pour garantir qu’ils prennent en compte les détails aussi bien que la vue à long terme.

Il n’y a aucune règle générale sur la façon de gérer ces situations. C’est pour beaucoup une approche ad hoc pour laquelle le chef de projet doit être préparé en comprenant la complexité des relations entre organisations. C’est comme tirer sur une corde où le PM doit deviner quand tirer sur celle-ci et quand lâcher un peu de mou.

Note perso: Comme le rappelle Garr Reynolds dans cette vidéo, la flexibilité du bambou peut être sa plus grande force…

Méta Projets Management

Partenaire de DantotsuPM

le changement et l’importance des incitations dans les projets

20 avr

Change & The Importance of Incentives

http://philipdiab.com/2011/09/incentives/

par Philip R. Diab

Un des prérequis de succès sur tout projet est à mon avis les incitations. Les parties prenantes, spécifiquement le groupe d’usagers et clients doit avoir assez de motivations à supporter le livrable du projet, produit et/ou service. J’ai vu beaucoup de projets où une organisation a acheté une nouvelle solution logicielle ou une autre sorte de produit mais le groupe d’usagers n’a pas été correctement engagé pour assurer que le produit/service soit utilisé. Ceci n’arrive pas seulement dans des projets où un élément d’obtention de prime existe mais peut avoir lieu sur une variété d’initiatives.

un exemple de la vie courante : un programme de recyclage des ordures ménagères

Un exemple particulier qui me met en évidence le problème des primes est basé sur une expérience récente que nous avons eue avec la municipalité d’une ville dans laquelle nous vivons. Je vis dans une zone urbaine avec une variété d’immeubles d’habitation et des maisons familiales indépendantes. La communauté est configurée d’une telle façon que la collection d’ordures est faite via de grandes poubelles à ordures communes qui sont vidées par la ville dans ses camions sur une base quotidienne. Notre ville est par conséquent relativement propre, cependant elle n’aborde pas la question du recyclage comme partie intégrante de ses services.

J’étais heureux de voir il y a plusieurs semaines que la ville a initié un programme de recyclage qui tient en partie dans l’éducation et la prise de conscience et en partie une réorganisation des poubelles. Chaque immeuble/maison a reçu un avis selon lequel la ville leur enverra des poubelles de recyclage. En outre, la ville a publié une lettre qui explique comment le processus marchera et comment les diverses ordures seront ramassées.

Alors, après la dépense significative et l’effort mis dans le projet j’ai été étonné de voir que le jour où les nouvelles poubelles ont été livrées les vieilles sont restées en place. Comme je l’ai observé pendant la semaine suivante, j’étais à nouveau étonné que peu de voisins utilisent les nouvelles poubelles. En fait, chacun a continué les mêmes habitudes qu’auparavant. Ils amenaient leurs ordures aux vieilles poubelles, laissant les nouvelles propres et vides.

qu’en retenir?

Ceci est pour moi un exemple parfait qui démontre que malgré l’éducation et l’engagement communautaire, le groupe de parties prenantes principales ne coopérait pas pour une raison simple : Pour cette communauté, il n’y avait aucune incitation à changer le comportement. Peut-être que des collaborateurs de la ville ont pensé que les nouvelles poubelles d’ordures étaient une motivation suffisante. Cependant, personne ne semble avoir pensé à supprimer les anciennes. Alors que nous nous associons souvent les incitations au potentiel de récompense des membres de l’équipe ou des parties prenantes s’ils exécutent certaines tâches ou se comportent d’une certaine façon, parfois les incitations doivent être concentrées sur le changement de l’environnement pour pousser les gens dans la bonne direction.

incitationIl sera intéressant de voir comment la ville jugera du succès de ce nouveau programme, cependant, une pensée qui a traversé mon esprit est qu’ils faisaient peut-être un premier essai. En tant que tel ils ont décidé de laisser les vieilles poubelles jusqu’à ce qu’ils aient vu que la communauté était à l’aise avec les nouvelles.

Il est en effet difficile de spéculer et je n’ai pas l’intention de critiquer cette initiative importante, d’autant que j’ai pensé que c’est une étude de cas intéressante qui reflète ce qui arrive sur des projets, dont certains dans lesquels j’ai été impliqué.

Méta Projets Management

Partenaire de DantotsuPM

20 questions que tous les chefs de projet devraient poser

6 mar

20 Questions All Project Managers Should Ask

http://www.pmhut.com/20-questions-all-project-managers-should-ask par Michelle Symonds

Une des nombreuses compétences requises d’un chef de projet est la capacité à poser des questions et à persévérer jusqu’à ce qu’une réponse claire soit obtenue. Beaucoup de pièges dans les projets pourraient être évités si les questions étaient pleinement articulées et si on obtenait des réponses claires et détaillées.

Trop souvent les secteurs d’un projet qui devrait être clairement définis ne le sont pas. Des assomptions sont faites sur qui est responsable de quoi, et même pire, des suppositions sont faites sur ce que sont exactement les objectifs fonctionnels et quels bénéfices le projet apportera à l’organisation.

Dans notre enthousiasme à commencer sur un nouveau projet passionnant, il est facile pour chacun, pas seulement le chef de projet, de se jeter dans les premières étapes de préparation d’un projet et la découverte de ses parties passionnantes. Mais, en ces temps économiques incertains, chaque projet devrait amener des bénéfices substantiels au business et qui puissent être précisément mesurés. Les bénéfices pourraient être des réductions de délais ou de coûts, mais ils pourraient également avoir pour objet de maintenir une certaine réputation (ou la rétablir). Ils ne sont donc pas toujours faciles à mesurer et ne peuvent pas toujours être précisément estimés à l’avance. Néanmoins, les avantages attendus devraient être documentés pour que soit clair pour toute personne impliquée pourquoi le projet est nécessaire.

Aucune liste de questions n’est jamais complète, mais voici 20 questions qu’un chef de projet devrait toujours poser, indépendamment du type de projet sur lequel il travaille et quelque soit le type d’organisation :

  1. Quels sont les objectifs business que le projet aspire à réaliser ?
  2. Quel bénéfices business ces objectifs délivreront-ils si atteints ?
  3. Quelles seront les conséquences sur le business (financières, réputation, etc.) si le projet n’est pas entrepris ou échoue à atteindre les objectifs ?
  4. Existe-t-il des alternatives “faciles à réaliser” à ce projet ? Parfois d’autres solutions existent qui n’exigeront pas les mêmes coûts qu’un projet complet.
  5. Y-a-t-il des inconvénients à l’implémentation de ce projet ? Des licenciements économiques pourraient être nécessaires, mais il pourrait y en avoir d’autres moins évidents.
  6. regarder vers le hautQui est la partie prenante principale, avec la responsabilité suprême de piloter le projet à terme ? Il est important que quelqu’un de senior prenne la propriété d’un projet. Cette personne ne devrait jamais être le chef de projet.
  7. Qui est responsable d’assurer des ressources appropriées (le temps, les personnes et l’argent) sont allouées au projet ? Cela devrait être quelqu’un avec l’autorité pour allouer toute ressource exigée.
  8. Qui sera responsable de se décider si le projet continue ou pas après les enquêtes préliminaires ? Ce sera souvent un groupe de personnes, parfois avec des buts conflictuels.
  9. Le nouveau projet dépend-il de la livraison réussie d’un projet actuel ? Si c’est le cas,  un rapport complet sur le statut du projet en cours de réalisation devrait être obtenu avant de s’engager sur le nouveau projet.
  10. Quels sont les critères de succès qui indiqueront que les objectifs ont été atteints et les bénéfices obtenus ?
  11. De nouveaux équipement/produits seront-ils exigés pour permettre la réalisation du projet, par exemple un nouveau logiciel est-il nécessaire ?
  12. Y aura-t-il des changements de personnel nécessaires (des licenciements économiques ou de nouvelles embauches) ?
  13. Le personnel existant aura-t-il besoin de formation, par exemple apprendre de nouveaux processus métier ?
  14. Quelles personnes, équipes ou organisations seront impliqués dans le projet ?
  15. Qui sera responsable de documenter les besoins business dans le détail ?
  16. Qui déterminera les délais intermédiaires et finaux ? Les projets où le service marketing, par exemple, choisit un délai ferme pour un projet informatique ont un beaucoup moins réussi que quand des évaluations éduquées sont faites par les ressources requises.
  17. Combien de provisions seront disponibles dans le budget ?
  18. Qui sera responsable de prendre les décisions pour inclure ou exclure des changements demandés une fois que le projet est démarré ?
  19. Les livrables de projet devront-ils être testés et, s’il en est ainsi, par qui ?
  20. Qui fournira l’approbation finale du livrable de projet ?

Il y a beaucoup plus de questions que l’on pourrait poser pour s’assurer qu’un projet commence avec de bonnes chances de succès. Mais il est aussi important d’obtenir des réponses appropriées. La majorité des gens aura reçu la formation nécessaire pour aider les chefs de projet à développer une série des questions qui soit la plus adéquate pour leur domaine d’activité. Ceux qui sont nouveaux dans le management de projet peuvent bénéficier de bases de connaissances comme APM Introductory Certification ou une des certifications PMI.

Quelles autres questions vous posez-vous avant de commencer un nouveau projet?

Méta Projets Management

Partenaire de DantotsuPM

27 mars – Sophia – Agile Management, complexity thinking, change management

2 mar

Telecom ValleyConférence Telecom Valley

www.telecom-valley.fr/blog/conference-agile-management

Dans un concert mondial en mutation rapide, l’avenir des TIC de notre région est de plus en plus lié à l’emploi de business models disruptifs (Open Source) et de méthodologies innovantes (agiles) pour pouvoir se positionner efficacement et durablement. Forte des différentes manifestations organisées par la commission Open Source de Telecom Valley, dont notamment SophiaConf2010 et 2011 qui ont par deux fois accueilli des conférences sur les méthodes agiles, ainsi que l’étape Agile Tour de Sophia Antipolis, sur laquelle l’association était co-organisateur en 2011, Telecom Valley organise le 27 mars 2012 la conférence « Agile Management » à Sophia Antipolis.

Cette conférence a pour objectif de permettre aux managers, dirigeants et professionnels sophipolitains de découvrir ou mieux connaitre la vision et les bonnes pratiques du « Management 3.0 » par l’un des pères fondateurs des méthodes agiles pour le management, Jurgen Appelo, et d’échanger avec lui sur le sujet.

Programme

Conférence gratuite animée entièrement en anglais par Jurgen Appelo.

17h00 : Accueil

17h30 – 20h30 : Jurgen Appelo

  • “Agile Management: Why do we need management & leadership?”   (45 min)
  • “Complexity Thinking: How must we solve problems in organizations?”  (45 min)
  • “How to Change the World: How can we change behavior of people?”   (1h15)

20h30 : Cocktail

La participation est gratuite sous réserve d’inscription en ligne en cliquant ici.

Et pour ceux qui veulent approfondir le sujet, CampusID Training Center propose de passer 2 jours de formation avec Jurgen les 28 et 29 Mars. www.trainingcenter.fr

5 techniques de management de projet Agiles que vous pouvez commencer à utiliser dès aujourd’hui

14 fév

5 Agile Project Management Techniques You Can Start Using Today

http://www.pmhut.com/5-agile-project-management-techniques-you-can-start-using-today

Par Joel Semeniuk

démarrer commencer“Le secret du progrès est de commencer. Le secret pour commencer est de découper vos tâches complexes et écrasantes en de petites tâches gérables puis de commencer par la première.” Mark Twain

Mark Twain n’était pas un manager de Développement Logiciel; cependant, ses mots résonnent toujours de manière très juste quand on en vient à comment vous pouvez commencer à adopter les Techniques Agiles de management de projet.

Voici les 5 premières pratiques que vous pouvez utiliser Aujourd’hui indépendamment de votre situation ou environnement.

1.    Ne l’appelez pas “Agile” – Le terme Agile semble être devenu usé ou simplement sur ou mal utilisé. Dans quelques organisations, il a même des connotations négatives,  synonyme de “centré sur le développeur” ou “aucune documentation” ou “aucun besoin défini”. Ce n’est pas l’intention d’Agile. De plus, parfois le terme “Agile” fait apparaître un dogme, comme une poussée religieuse d’aller vers le “tout ou rien” dans l’adoption de toutes les choses “Agiles”. Dans des nombreux cas, ce n’est tout simplement pas la réalité. En fin de compte nous adoptons des pratiques de management de projet “Agiles” pour aider à contrôler le chaos et, ce qui est plus important, réduire les déchets en nous aidant à nous concentrer sur la production de valeur pour le business. Le terme “Agile” fait parfois appel à un état final nébuleux qui semble inaccessible ou peu pratique dans beaucoup d’organisations. Alors, pourquoi appel cela Agile ? Le but d’adopter n’importe quelle pratique est quasiment le même : réduire au minimum les déchets. Vous n’avez pas à étiqueter l’une de ces pratiques du terme “Agile” si vous ne voulez pas et pourtant toujours en obtenir une énorme valeur.

stand up meeting2.    Cadences de Communication à haut débit et large bande bornées dans le temps – Le terme “Haut débit” est utilisé pour une bonne raison. Une partie “d’Agile” est une reconnaissance que les gens communiquent plus efficacement quand ils sont face à face, les autres façons générant du gaspillage. Nous aimons les discussions en face à face. Le langage du corps, les expressions du visage et la conversation interactive ajoutent tous à l’efficacité de cette forme de collaboration. Étant donné cela, vous devriez commencer à saupoudrer à cadence régulière les communications à haut débit dans votre projet. Pour faire cet encore plus efficace, envisagez de placer une limite de temps sur ces sessions pour vous assurer que chacun reste concentré. Ne confondez pas cela avec “plus de réunions”. Implémenter cela correctement aboutit à moins de réunions mais plus efficaces en se concentrant sur une meilleure communication d’équipe. Commencez par une réunion de 15 minute quotidienne “stand-up” où les membres de l’équipe présentent simplement ce sur quoi ils travaillent et tout problème. Ensuite, introduisez un bihebdomadaire “montrer-et-dire” (« show-and-tell ») avec vos clients pour montrer ce qui a été accompli pendant cette période. Si vous ne pouvez pas vous rencontrer en face à face, pensez donc à d’autres formes de communication à haut débit et large bande comme le chat vidéo avec Skype ou Lync. Essayez de ne pas compter sur le courrier électronique comme forme principale de discussion car plus vous comptez sur des mots écrits pour la communication et plus la signification et l’intention y sont rapidement perdus ou mal interprétés.

3.    Soyez Visible – Trouver une manière de communiquer simplement et efficacement l’état actuel d’avancement. Je pourrais souligner que ce n’est pas une impression de 50 pages de votre Gantt chart Microsoft Project mais plutôt un tableau très simple, très visible qui montre ce sur quoi les gens travaillent. Cela ne doit pas être électronique et pourrait être aussi simple que des post-it sur un tableau blanc. Il y a des tas d’exemples de cela. Encore que vous devriez commencer avec quelque chose de simple à créer et, ce qui est plus important, simple à maintenir et à mettre à jour.

4.    Contrôlez Régulièrement – Le terme de Post-mortem est un terme horrible. Cela signifie examiner quelque chose après qu’elle soit morte. Au lieu d’utiliser une autopsie pour amener l’apprentissage organisationnel, pourquoi ne pas avoir “un point de contrôle régulier” pour vous assurer que vous faites tout ce que vous pouvez pour garder le projet et l’équipe en bonne santé ? Cela ne doit pas être formel. Cela peut être aussi simple qu’une “pizza du vendredi” le dernier vendredi du mois où l’équipe se réunit pour bavarder de ce dont ils pensent que ça va bien et ce qu’ils savent avoir besoin de réparations.

5.    Définissez « Fait » – Au lieu d’avoir des chiffres arbitraires qui représentent le % “de fait” de quelque chose, créez une check-list, une liste de contrôle, que vous et votre équipe acceptez comme définition de ce que signifie exactement être “fait” pour des tâches de types différents. Vous pouvez avoir une check-list “fait” pour vos tâches d’analyse et une autre check-list pour d’autres étapes dans le processus de développement. Les check-list sont très faciles à produire et devraient commencer en étant très simples. Vous pouvez utiliser vos réunions de contrôle régulières pour ajouter ou supprimer des éléments de vos check-list afin de continuer à capturer les leçons apprises de l’équipe et améliorer la cohérence au sein de votre projet et pour tous les membres de l’équipe.

Ces 5 pratiques ne devraient pas être en conflit avec aucune méthode ni modèle que vous utilisez aujourd’hui et néanmoins vous apporter une aide précieuse tout au long de votre chemin vers l’adoption de pratiques encore plus Agiles.

PMGS Formations en management de projet

Partenaire de DantotsuPM

8 Février – Paris – Gouvernance et gestion du changement dans les projets

23 jan

PMI Ile de FranceLe PMI – Chapitre Paris Ile de France vous invite à participer à sa soirée sur le thème : Gouvernance et gestion du changement dans les projets à 18h00 à l’Espace Saint Martin –Salle Nicolas Roerich– Metro/RER Chatelet.

Programme:

- 18h00 : Accueil à l’espace Saint Martin.

- 18h30 : Fabio Panzavolta : Définition d’une gouvernance de programme pour stimuler le décloisonnement des équipes IT et Métier

Quand on démarre un nouveau projet, rapidement on doit comprendre et emmagasiner beaucoup d’informations. En premier lieu, il est important de définir une organisation adaptée aux besoins, aux contraintes et aux objectifs à atteindre par le projet. Comment obtenir une organisation harmonieuse, décloisonner les acteurs projets, comprendre et faire comprendre le mode de fonctionnement des autres « mondes », bref partager la diversité est un des éléments clé de réussite pour un projet. Lors de cette soirée, je partagerai mon expérience récente concernant cette problématique, les résultats atteints et on échangera (sans modération) pour qu’on puisse s’enrichir les uns avec les autres.

Fabio Panzavolta est consultant depuis 10 ans, Italien d’origine, Fabio arrive en France en 2001 pour travailler au sein d’un grand groupe international. Six ans dans l’industrie, puis trois ans au sein d’une start-up française, lui ont permis d’intervenir à toutes les phases de grands projets informatiques que ce soit en tant qu’expert informatique ou manager de projets. Aujourd’hui consultant en Management de Projets et Programmes, il intervient auprès de grands comptes pour accompagner des projets complexes, à l’international, et mettre en place de l’ingénierie de projet.

- 19h30 : Yves Cavarec (IsValue) : Choisissez votre approche de gestion du changement pour vos projets.

Descriptif : Tout le monde cherche une méthode pour gérer la transformation des organisations, ou les impacts humains des projets ou encore le fameux facteur humain, grain de sable dans le rouage si parfait de l‘ingénieur.  Une approche adéquate des changements est un facteur clé de succès des projets à fort impact.  S’il n’existe pas (hélas !) de méthode infaillible, le chef de projet a néanmoins le choix entre plusieurs approches.  Leurs avantages et inconvénients sont passés en revue lors de la conférence.  Des exemples illustrent les différences entre ces approches.

Yves Cavarec est consultant depuis 15 ans, conférenciers dans plusieurs écoles de management et auteur en 2011 du livre « Cherry picking 1.0 – l’informatique :  opportunités et menaces pour l’entreprise ».  Son expertise porte sur les liens entre performance, organisation, projets et systèmes d’information.  Yves est speaker au PMI Global Congress à Dublin en 2011 et à Marseille 2012.  Il est par ailleurs volontaire au PMI depuis 2006.  Il œuvre à l’union des chapitres PMI en France.  Il a initié un groupe de travail sur le management des changements dans les organisations au sein de la Community of Practice « Organization Project Management » du PMI : http://opm.vc.pmi.org/

- 20h30  : Venez rencontrer vos pairs autour d’un verre et discuter avec les membres du bureau.

Inscriptions : Les inscriptions se font sur le site Internet du PMI Chapitre Paris Ile-de-France.

- 10 € pour les membres du chapitre et assimilés ; - 20 € pour les non membres. Cette soirée rapportera 2 PDU aux PMPs.

Méta Projets Management

Partenaire de DantotsuPM

conseils utiles pour manager les changements de contenu de projet

29 nov

Comme toujours, j’apprécie le ton humoristique des billets de Michaël qui touche des points sensibles du management de projet. Ici, il partage son expérience sur la gestion des changements.

Helpful Advice for Managing Project Scope Change

http://www.pmhut.com/helpful-advice-for-managing-project-scope-change par Michael Stanleigh

Cher Docteur Projet :

Mon projet est un constant défi. Leurs managers retirent souvent des ressources assignées pour faire d’autres boulots ou projets. Les consultants achèvent souvent leurs livrables en retard. Le budget dépasse nos coûts à ce point dans le projet et les clients deviennent impatients de recevoir le nouveau produit et service. Notre date originale prévue pour le lancement était maintenant. Notre nouvelle date d’achèvement est ciblée pour dans 6 mois.

Maintenant mon sponsor vient de venir me voir avec la requête la plus ridicule que j’ai jamais entendue! Il veut que mon projet soit complété dans 2 mois ou moins. Aucune augmentation budgétaire. Aucune ressource supplémentaire ajoutée. Quand j’ai demandé comment il espérait que je réussisse, il a rétorqué “Vous êtes le chef de projet. Trouvez comment faire”.

Je ne sais pas par où commencer. Comment manager cette nouvelle contrainte ? Je travaille déjà de longues heures.

J’attends avec impatience votre conseil,

Signé : Désespéré

Cher Désespéré :

Étonnamment, c’est un dilemme très courant et une contrainte majeure sur la capacité des projets à être managés avec succès. Cependant, il existe une solution simple.

Je sais que notre réponse première et préférée serait de retourner cette requête apparemment peu raisonnable au Sponsor et lui dire que ce n’est pas possible. La vérité est que nous ne pouvons pas faire cela. Nous devons manager cette requête et agir comme nous le ferions pour toute modification de projet.

Cette requête est identifiée comme un “Changement de Contenu”. Ceci se réfère à quoi que ce soit qui sera maintenant différent de ce qui avait été accepté à l’origine dans la Déclaration de Contenu originale de Projet et par la suite le Plan de Projet. La requête de votre sponsor entre certainement dans cette catégorie. Voici que faire :

  • Commencez une analyse sur la requête du sponsor. Vous voudrez explorer comment ce “Changement de Contenu” affectera les coûts de votre projet, l’échéancier et les besoins clients et identifier l’impact du changement pour chacune de ces catégories majeures. Recherchez et enregistrez les options ou alternatives associées au changement demandé. Cela inclut les deux options suivantes:
    1. Donnez plus de temps au projet pour qu’il y ait une probabilité plus forte que les besoins clients puissent être satisfaits.
    2. Faites avec la contrainte de temps présentée mais ajoutez davantage de ressources et de budget pour vous assurer que les besoins clients seront satisfaits.
  • Documentez une Requête de Changement. Le formulaire de demande de changement doit inclure :
    1. L’impact de ce changement sur le projet – incluant son coût, échéancier, client et tout autre facteur.
    2. sélectionner une idéeLes options pour traiter le changement; c’est-à-dire, approuver l’option a ou b.
    3. Votre recommandation et les approbations requises avant de donner suite au changement.
  • Passez en revue le formulaire rempli avec votre Sponsor. Discutez des impacts du changement et des options. Essentiellement, vous essayez d’instruire votre sponsor. Les sponsors viendront souvent vers vous avec des requêtes apparemment peu raisonnables parce qu’ils ne peuvent pas entièrement comprendre l’impact que de telles requêtes peuvent avoir sur le projet ou les défis auxquels votre équipe projet peut faire face pour les implémenter avec succès.

Bien que n’étant pas une garantie de succès, en appliquant une évaluation méthodique du changement demandé par le Sponsor, vous augmenterez la probabilité que votre Sponsor comprenne le plein impact de sa requête de modification tant sur le client que sur le projet et soit plus susceptible d’accepter vos recommandations quant au changement.

Tenez-moi s’il vous plaît au courant de l’impact de l’utilisation de ce processus de management de requête de changement,

Signé: Docteur Projet

comment empêcher que la dérive de contenu n’emporte au loin votre projet

11 oct

Stop Scope Creep Running Away With Your Project

http://www.projectsmart.co.uk/stop-scope-creep-running-away-with-your-project.html

Duncan Haughey, PMP

La dérive de contenu est une des raisons les plus communes pour laquelle les projets dépassent leur budget et livrent en retard. Souvent acceptés avec les meilleures intentions, les changements de contenu pendant un projet sont des événements négatifs qu’il vaut mieux éviter.

La plupart des chefs de projet se sont trouvés dans le cas où le client demande quelque chose à l’extérieur du périmètre accepté et s’attend à la voir incluse sans frais supplémentaires. En fait, ils agissent probablement comme si cela avait toujours fait partie du contenu.

La définition des limites d’un projet est difficile, mais sans une définition claire vous vous dirigez vers des problèmes.

Qu’est-ce que le contenu de projet ?

La description du contenu est ce qu’un chef de projet s’engage à livrer tôt dans la vie d’un projet. Le contenu est défini pendant la phase d’analyse des besoins d’un projet. Travaillant étroitement avec le client et les utilisateurs, le chef de projet identifie ce qui est nécessaire pour atteindre les objectifs de projet. Le contenu de projet est enregistré dans la documentation de projet et agréé avec toutes les parties prenantes affectées.

Qu’est-ce qui cause la dérive de contenu ?

Les causes majeures de dérive de contenu sont :

  • Pauvre analyse des besoins.
  • Implication trop tardive des utilisateurs.
  • Sous-estimation de la complexité du projet.
  • Manque de contrôle des changements.
  • « Sur » qualité.

Jetons un coup d’œil à chacune plus en détail :

Pauvre analyse des besoins

Le Problème :

Les clients ne savent pas toujours exactement ce qu’ils veulent et ont souvent seulement une vague idée. Le Syndrome “Je le saurai quand je le verrai”. L’échec de passer assez de temps à rassembler des besoins du business (ou assumer que l’on sait ce qui est nécessaire) peut mener à un besoin de ressources supplémentaires, un accroissement des coûts et des allongements de durées quand de nouveaux besoin apparaissent; en bref, une dérive de contenu.

La Solution :

Assurez que vous comprenez la vision de projet et passez du temps à documenter et agréer les objectifs de projet avec le client. Produisez un document de d’initiation de projet qui décrit les produits à livrer et le résultat. C’est une bonne idée de documenter ce qui est hors périmètre, aussi bien que ce qui est dans le périmètre, pour une absolue clarté. Agréez ce document avec le client, passez du temps pour le revoir en détail et demandez-leur de le signer. Ne poursuivez pas sans un accord ferme.

Implication trop tardive des utilisateurs

Le Problème :

en retardPenser de vous savez ce que veulent les utilisateurs ou leurs besoins est une sérieuse erreur. Il est important de les impliquer dans les phases d’analyse des besoins et de conception. Plus ils ont d’engagement au début du projet, plus probablement cela vous évitera une dérive de contenu.

La Solution :

Impliquez vos utilisateurs depuis le début du projet, leur permettant de participer aux phases d’analyse des besoins et de conception; incorporez leurs suggestions et idées. Dans un projet de développement logiciel, documentez comment les utilisateurs interagiront avec le logiciel et développez des scénarios de test à utiliser plus tard. Agréez l’analyse des besoins et la conception avec toutes les parties prenantes du projet avant de démarrer la phase d’exécution.

Sous-estimation de la Complexité du Projet

Le Problème :

Le succès ou l’échec d’un projet peuvent souvent être prévus en regardant si des projets semblables ont été réussis par le passé.

Beaucoup de projets se heurtent aux problèmes parce qu’ils sont nouveaux dans leur industrie et n’ont jamais été réalisés auparavant. Personne ne sait à quoi s’attendre, il n’y a aucune leçon apprise et personne à qui demander. Dans ces circonstances, une dérive de contenu peut difficilement être évitée, causant des dépassements budgétaires et une livraison en retard.

utiliser les provisionsLa Solution :

Ces types de besoins de projet exigent d’avoir un degré de provisions pour aléas. Incluez certaines marges dans votre plan de projet afin de prévoir pour des problèmes et des événements imprévus et augmentez le budget pour représenter les ressources supplémentaires qui pourraient être nécessaires. Cependant, n’exagérez pas, être significativement en dessous du budget et livrer plus tôt est souvent considéré négativement.

Manque de Contrôle des Changements

Le Problème :

Vous pouvez vous attendre à un certain degré de risque de dérive du contenu dans la plupart des projets, donc il est important de concevoir un processus pour manager ces changements. Un processus simple consistant à documenter, considérer, approuver et trouver les ressources peut être conduit.

La Solution :

Introduisez un formulaire de contrôle des changements et un journal/registre des changements dès le début du projet. Expliquez leur utilisation au client et à l’équipe projet. Une requête de changement formellement écrite vous permettra d’évaluer le bénéfice business de tout changement et de rechercher son approbation éventuelle avant de l’inclure en tant qu’addition au contenu. Attachez un coût et une durée à chaque changement pour que le client comprenne bien son impact. Demander au client de passer par un processus formel aide à s’assurer qu’il y a une valeur claire pour le changement recherché.

« sur » qualité (Gold Plating)

Le Problème :

« Gold Plating » est le terme donné à la pratique d’excéder le contenu ou la qualité d’un projet en pensant que cela ajoute de la valeur. Dans des projets de développement logiciels, il n’est pas inhabituel pour des développeurs d’ajouter de nouvelles fonctionnalités croyant qu’elles augmenteront la satisfaction du client. Ces changements consomment du temps et du budget et ne garantissent pas d’augmenter la satisfaction client.

La Solution :

Assurez-vous que tous les membres de l’équipe sont pleinement conscients du contenu du projet et concentré sur livrer cela et rien de plus. Assurez-vous que le cahier des charges est suffisamment détaillé pour éviter toute ambiguïté qui pourrait mener à du travail inutile.

Récompensez des membres de l’équipe pour livrer selon la spécification, à l’heure et dans le budget. Précisez que des fonctionnalités non documentées ne devraient pas être ajoutées, mais passées par le processus de contrôle des changements.

S’il y a du temps et qu’il reste de l’argent à la fin du projet, laissez le client décider que faire.

Résumé

Pour récapituler, assurez-vous que vous positionnez correctement les attentes au début du projet, travaillez étroitement avec les utilisateurs pour définir clairement ce qui est dans et hors du périmètre. Enregistrez-le dans le document d’initiation de projet. Cependant, ne supposez pas que le client lira et comprendra ce document. Passez du temps avec le client à le revoir pas à pas et à vous assurer qu’ils comprennent et acceptent le contenu. Ne continuez pas sans accord ferme.

Souvent il n’est pas possible d’éviter que le contenu augmente pendant un projet, particulièrement s’il y a une bonne raison business de le faire. Cependant, il doit être géré correctement. Concevez un processus de contrôle des changements pour vous assurer que tous les changements sont correctement documentés, considérés, approuvés et approvisionnés en ressources. Note : Si le budget et la durée sont augmentés avec le contenu, habituellement, on ne considère pas le changement comme une dérive de contenu.

Alternativement, vous pouvez vouloir empêcher que des changements soient ajoutés petit à petit pendant le projet et pouvez décider de les documenter mais pour une phase ultérieure. Cela permet à la phase acceptée d’être livrée à l’heure et dans le budget et aux changements d’être managés et dotés en ressources séparément.

Si vous considérez que seulement 32 % ¹ de tous les projets réussissent pleinement; alors vous êtes mieux lotis à dépenser votre temps à livrer par rapport aux besoins acceptés en début du projet et à éviter la « sur » qualité.

La dérive de contenu cause beaucoup d’échecs de projet; en prenant quelques mesures simples vous pouvez vous assurer qu’elle n’affecte pas les vôtres.

¹ The Standish Group International, Inc. CHAOS Summary 2009. Boston, MA 02109: The Standish Group International, Inc., 2009.

http://www.standishgroup.com/newsroom/chaos_2009.php

manager la dérive de contenu de projet

26 sept

Managing Scope Creep in Project Management

http://www.pmhut.com/managing-scope-creep-in-project-management

By Claudia Vandermilt

Les chefs de projet ont été tourmentés par la dérive de contenu depuis l’aube du management de projet. Manager la dérive de contenu dans le management de projet est un travail difficile qui nécessite un cahier des charges clairement défini, documenté et contrôlé. La dérive de contenu peut se glisser à l’intérieur, transformer et détruire un projet.

Contenu de Projet Défini

Que signifie “contenu de projet”? Simplement exposés, ce sont les paramètres du projet. Le contenu de projet devrait être identifié avec une description détaillée et comprenant tous les produits majeurs et toute limite du périmètre du projet. Il doit inclure des informations suffisantes pour que l’équipe projet puisse produire le livrable désiré dans les temps et dans le budget. En général, le contenu de projet est déterminé tôt dans le processus, documenté et convenu avec toutes les parties prenantes du projet. Comment survient la dérive de contenu ?

Même quand il y un contenu clairement défini de projet, vous devez toujours prendre garde à la dérive de contenu. Ce phénomène a généralement tendance à se matérialiser quand de nouvelles fonctionnalités sont ajoutées au design de livrables qui ont déjà été approuvés, sans fournir des accroissements équivalents de budget, temps et/ou ressources. Project Smart, basé au Royaume-Uni, constate que les causes principales de dérive de contenu sont :

  • Pauvre Analyse de Besoins: Les clients ne savent pas toujours ce qu’ils veulent et peuvent seulement fournir une vague idée. Le syndrome “Je le saurai quand je le verrai”.
  • Implication trop tardive des utilisateurs: Penser que vous savez ce que veulent les utilisateurs ou connaissez le besoin est une sérieuse erreur. Il est important de les impliquer dans tous les phases d’analyse des besoins et de conception.
  • Sous-estimation de la complexité du projet: Beaucoup de projets rencontrent des problèmes parce qu’ils sont nouveaux dans une industrie et n’ont jamais été réalisés auparavant. Personne ne sait à quoi s’attendre, il n’y a pas de leçons apprises et personne à qui demander.
  • Manque de contrôle des changements: Vous pouvez vous attendre à un degré de dérive de contenu dans la plupart des projets, donc il est important de concevoir un processus pour gérer ces changements. Un processus simple pour documenter, considérer, approuver et ressourcer peut être implémenté.
  • Placage à l’or fin: On donne ce terme à la pratique consistant à augmenter le contenu d’un projet en pensant que de la valeur est ajoutée. Ces changements consomment inévitablement du temps et de l’argent et ne garantissent pas d’accroître la satisfaction client.

Davantage de raisons à la dérive de contenu

Ce n’est nullement un secret que manager la dérive de contenu dans le management de projet peut être un défi intimidant. Puisque le contenu de projet est souvent fluide de par sa nature, il a tendance à se transformer comme progresse le projet. Cependant, il peut facilement devenir désastreux si on lui permet de sortir de notre contrôle. Par exemple, Wikipédia liste les causes suivantes à la dérive de contenu :

  • Client peu sincère avec une politique déterminée du “tout gratuit”
  • Pauvre communication entre les parties prenantes
  • Manque d’identification initiale appropriée de ce qui est exigé pour atteindre les objectifs de projet
  • Faiblesse du contrôle des changements
  • Chef de projet ou sponsor exécutif faible
  • Développement logiciel Agile basé sur des estimations subjectives

Ahurissantes Statistiques de Projet

Bien que la dérive de contenu ne soit pas la seule Némésis qu’un projet puisse avoir, elle a vraiment tendance à avoir l’impact le plus important. Sans un projet correctement défini et/ou en permettant de nombreux changements en chemin, un projet peut facilement dépasser son budget, louper les délais et faire des ravages. Sans surprise, moins d’un tiers des projets sont achevés dans les temps et dans le budget. Le rapport CHAOS 2009 du Standish Groupe a trouvé que :

  • 32 % de tous les projets étaient réussis, signifiant livrés à l’heure, dans le budget, avec les fonctionnalités requises
  • 44 % ont été en danger; ces projets ont été en retard, ont dépassé le budget, et/ou avec livré moins que les fonctionnalités requises
  • 24 % ont échoué, signifiant annulés avant l’achèvement ou livrés et jamais utilisés

“Ces pourcentages représentent une chute des taux de réussites par rapport à l’étude précédente et ‘une augmentation significative du nombre d’échecs,” dit Jim Crear, CIO du Groupe Standish. “Ce sont les plus faibles résultats des cinq dernières périodes d’étude. Les résultats de cette année représentent le taux d’échec le plus haut depuis plus d’une décennie.”

Comment contrôler la dérive de contenu

Manager la dérive de contenu dans le management de projet est faisable. Un article récent de la Tech Republic, un site Web Interactif de CBS, fournit les instructions suivantes pour vous préparer avec succès à contrôler la dérive de contenu de votre projet :

    1. quelles sont les priorités?Soyez certain que vous comprenez à fond la vision du projet. Rencontrez les partie prenantes clés du projet et donnez-leur une vue d’ensemble du projet pour revue et commentaires.
    2. Comprenez vos priorités et les priorités des éléments clés du projet. Faites une liste priorisée à laquelle vous pouvez vous référer pendant toute la durée du projet. Les items devraient inclure le budget, les délais, les fonctionnalités à livrer, la satisfaction client et la satisfaction des collaborateurs. Vous utiliserez cette liste pour justifier vos décisions de planification une fois que le projet a commencé.
    3. Définissez vos produits et faites-les approuver par les sponsors de projet. Les produits devraient être les descriptions générales de fonction à être décrit pendant le projet.
    4. Décomposez les livrables approuvés en demandes réelles de travail. Les demandes de travail devraient être aussi détaillées que nécessaire et peuvent être suivies en utilisant un simple tableur. Plus votre projet est grand, plus vous devriez inclure de détails. Si votre projet dure plus d’un mois ou deux, n’oubliez pas d’inclure du temps pour des mises à jour logicielles pendant le développement et prévoyez toujours du temps pour une documentation suffisante.
    5. Découpez le projet en jalons majeurs et secondaires et préparez un échéancier de projet à faire approuver par les parties prenantes clés de projet. Des jalons secondaires ne devraient pas dépasser un mois. Indépendamment de votre méthode pour déterminer la durée de tâche, laissez de la marge pour les erreurs. Quand je travaille avec un personnel que je ne connais pas, je prévois généralement 140 % à 160 % de la durée comme prévision de livraison. Si votre échéancier est serré, réévaluez vos livrables. Livrer sous le budget et en avance laisse de la place pour des améliorations supplémentaires.
    6. Une fois qu’un échéancier a été créé, assignez les ressources et déterminez votre chemin critique en utilisant une technique d’évaluation et de revue de projet de type diagramme de PERT ou structure de répartition de travail (Work Breakdown Structure : WBS). Votre chemin critique changera pendant votre projet, donc il est important de l’évaluer avant de commencer le développement. Suivez ce chemin pour déterminer quels produits doivent absolument être complétés dans les temps. Dans de très grands projets, n’essayez pas de définir trop tôt les détails de phase, mais même un plan général vous donnera le réseau dorsal dont vous avez besoin pour une exécution réussie.
    7. Attendez-vous à ce qu’il y ait de la dérive de contenu. Implémentez des formulaires de demande de changement et formez les parties prenantes de projet à vos processus. Un formulaire de demande de changement vous permettra d’exécuter une analyse coûts-bénéfices avant de planifier tout changement demandé.

Si vous pouvez exécuter immédiatement toutes ces étapes, vous serez bien mieux placés pour réussir votre projet. Cependant, toutes les étapes que vous pouvez implémenter vous rapprocherons de pouvoir manager efficacement la dérive de contenu du projet. De cette façon, vous serez dans une meilleure position pour contrôler votre projet, au lieu que ce soit votre projet qui vous contrôle.

Méta Projets Management

Partenaire de DantotsuPM

les bonnes exigences pour bien les tracer ou bien les bonnes personnes pour un meilleur résultat?

21 sept

Stephen Carver, conférencier à Cranfield, a dirigé un groupe de travail interactif sur le management des exigences de projet et il est parvenu à d’excellentes conclusions en pensant hors des chemins habituels ! Son analogie entre l’aviation et le management de projets et de programmes est particulièrement pertinente et je suis certain que vous saurez en faire bon usage.

Alors, vous entez-vous davantage pilote de ligne, de chasse ou plutôt contrôleur aérien envers les projets que vous managez ?

← Entrées Précédentes

Suivre

Get every new post delivered to your Inbox.

Joignez-vous à 236 followers