Tag Archives: scope

6 Novembre – Paris – success story PMO et PM Practice

27 oct

PMIFR_Logo-Paris-Ile-de-FranceLa branche Paris Ile de France du PMI France vous invite à participer à sa conférence sur le thème :

A success story : la démarche graduelle de la mise en place d’un bureau de projets et la pratique de la gestion de projets dans les organisations

Jeudi 06 novembre 2014 à 18h00 à l’Espace Saint Martin –Salle Nicolas Roerich – Metro/RER Chatelet.

Les inscriptions se font sur le site Internet du PMI France

best practiceLors de cette conférence, on vous exposera comment la solution intégrée Efficient et ABAK 360  de SIRIUS Europe facilite la gestion de l’envergure et le périmètre de vos projets ainsi que la vigie de la planification, du contrôle et suivi de vos projets dans un tout intégré.   On verra à vous présenter également comment cette solution WEB permet d’optimiser la qualité de la reddition de comptes en automatisant notamment les rapports d’avancement des projets et diverses autres activités administratives reliées aux suivis budgétaires (projeter, réel et reste à faire), permettant par la même occasion de réduire les coûts et les efforts de gestion administrative des projets de 10 à 20%.

Au final, la conférence vous apportera comment la solution intégrée Efficient et ABAK 360 facilite l’utilisation des bonnes pratiques applicables en gestion de projets, tout en libérant les responsables de projet des aspects administratifs afin qu’ils se consacrent à  l’essence de leur rôle : GÉRER LE PROJET.

SMPP

Partenaire de DantotsuPM

votre premier projet, c’est simple comme 1-2-3 avec Prince2 selon Jeff Ball

6 août

Comment démarrer votre premier projet PRINCE2 en 3 étapes simples.

QRP International France

Partenaire de DantotsuPM

téléchargez le document PDF original à partir du site de QRP International

Vous avez suivi une formation PRINCE2, vous avez passé l’examen, vous êtes maintenant de retour à votre bureau, vous rouvrez le manuel de 350 pages, 19 chapitres et 26 documents …

Oui mais …. Par où commencer ?
… Simplifions les choses en 3 étapes !

1. Rédiger l’Exposé de Projet et faites-le approuver par votre exécutif

Comme son nom l’indique, l’Exposé de Projet est un document de synthèse. Il doit être facile à lire. Le manuel PRINCE2 suggère un modèle pour ce document : cependant, mieux vaut privilégier la lisibilité et la clarté plutôt que le formalisme et les détails.

L’Exposé doit contenir la structure organisationnelle du projet. Vous êtes le chef de projet, et vous avez besoin d’un Exécutif. C’est VITAL, le minimum vital. Sans Exécutif vous n’utilisez pas PRINCE2. L’Exécutif va assumer la responsabilité du projet. Vous allez exécuter en son nom le projet.

L’Exposé doit aussi contenir une description du produit du projet, votre livrable final. C’est important  de le documenter, c’est ce qui va définir votre périmètre. Le manuel PRINCE2 nous dit que c’est un document séparé mais vous pouvez l’inclure comme un paragraphe de votre Exposé.

Afin de définir correctement votre produit du projet, vous devez comprendre qui est votre client ou utilisateur (celui-ci peut être un client interne ou externe). Vous devez discuter de vos livrables avec votre client, pour comprendre leur besoin. L’Exposé de Projet doit inclure les exigences qualité du client et les critères d’acceptation.

Une fois l’Exposé rédigé, l’Exécutif doit le valider, vous ne pouvez pas continuer sans cela.

2. Créer une Structure de Décomposition du Produit et en obtenir l’approbation

Car-WBS

La structure de Décomposition du Produit (SDP) est un excellent moyen de comprendre ce qui doit être produit. Le SDP commence avec votre produit du projet, votre livrable final. Le SDP va vous donner plus de détails, 15 ou 20 livrables en tout.

Le moyen le plus simple de créer un SDP est de coller des post-it sur un tableau. Par ce biais il est facile de remodeler le SDP au fur et à mesure que les idées émergent. De manière idéale, faites-vous appuyer d’un collègue ou deux pour garantir une vision plus large. Une fois cela réalisé, convertissez les post-it en version électronique en utilisant un outil tel que Visio ou Powerpoint. C’est important de créer le SDP avant de commencer toute planification. Pour PRINCE2, le SDP est la première étape de planification.

Si vous utilisez un outil de planification, tel que MS Project ou même Excel, vous devez créer d’abord votre SDP et la faire approuver avant de commencer le travail avec ces outils. Votre PC doit être éteint !

Vous devez passer en revue la première version avec les acteurs clés : L’Exécutif, le client ou l’utilisateur et avec les chefs d’équipe qui vont produire la solution. Une fois approuvée vous pouvez créer le plan de projet autour des 15-20 livrables de votre SDP.

3. Créer un Cas d’Affaire en collaboration avec votre Exécutif.

Le cas d’affaire fourni la justification du projet. Il explique les ressources que le projet va utiliser et les compare avec les bénéfices escomptés. C’est un document important, cela dit, il doit être simple et court. Le problème avec le Cas d’Affaire est que l’on ne sait jamais quel niveau de détail est approprié. Votre Exécutif va vous guider sur ce point. N’ajoutez pas de détails superflus (si votre société n’a pas besoin d’exprimer les besoins en termes financiers, ne le faites pas).

balance temps vs ressourcesCommencez avec un résumé de votre besoin en ressources, et les bénéfices escomptés – pour de nombreux projets, c’est suffisant.

  • Les ressources sont habituellement des personnes et/ou de l’argent. Vous devez comprendre quels types de ressources sont nécessaires. (Par exemple, vous avez besoins de développeurs et de testeurs et de l’argent pour acheter les équipements).
  • La justification se base sur les bénéfices – obtenez les informations sur les bénéfices avec votre Exécutif. Tous les deux, vous devez comprendre les types de bénéfices que votre projet va générer (par exemple, réduction des coûts de production, de maintenance).

Une fois que vous avez un résumé vous pouvez détailler davantage, seulement si nécessaire. Il faudra peut-être convertir les ressources et les bénéfices en termes financiers. Vous aurez besoin probablement d’un calendrier et aussi d’un calcul financier complexe tel que la valeur actualisée nette. En tous les cas, simplifiez toujours les choses, n’effectuez pas le travail si ce n’est pas nécessaire.

3 poissons qui sortent du commun

1,2,3…

En trois étapes simples, on a les fondements de notre DIP (Documentation d’Initialisation de Projet).

Les trois piliers clés du DIP sont : l’Exposé de Projet, le Plan de Projet et le Cas d’Affaire. Ces trois étapes nous permettent de créer ces trois piliers. Voici la manière de mettre en pratique les concepts de votre formation PRINCE2 en trois étapes simples.

© Copyright QRP International 2013. Reproduction in full or part is prohibited without prior consent from QRP International.

 

Partenaire de DantotsuPM

Partenaire de DantotsuPM

5 façons d’éviter la dérive de contenu sur vos projets

16 mai

5 Ways to Avoid Scope Creep

Lire le billet original en anglais sur Projectmanager.com

change ahead

Image courtesy of mrpuen/ FreeDigitalPhotos.net

Un chef de projet travaillait sur un petit projet, trois mois pour livrer une nouvelle partie de logiciel. Après environ deux semaines, le sponsor de projet a décidé d’ajouter quelques nouveaux besoins. Le chef de projet les a incorporé. Un peu plus tard, le sponsor a fait un peu plus de changements et a demandé un peu de nouvelle fonctionnalité. De nouveau, le chef de projet a dit que ce n’était pas un problème. Les changements ont été faits. Vers la fin des trois mois, le sponsor est allé chez le chef de projet se plaindre que le projet soit en retard sur le calendrier. Le chef de projet a essayé d’expliquer que tous les changements signifiaient qu’il n’y avait aucune possibilité que le logiciel puisse être achevé dans le délai original. Le sponsor n’était pas content et le chef de projet a été viré du projet parce qu’il était « trop lent ».

Cela vous semble familier ? J’espère que non ! La dérive de contenu est ce qui arrive quand les changements sont faits sur la portée d’un projet sans contrôle. Bien sûr, les changements arrivent tout le temps dans les projets et il est très rare qu’un projet livre au final exactement ce que l’on avait demandé au premier jour. Cependant, les changements sans contrôle signifient que le chef de projet a une très faible chance de rester en contrôle du travail sur le projet et manager efficacement le projet.

La dérive de contenu prend généralement la forme de nouveaux besoins qui sont ajoutés après que le projet ait commencé.

Typiquement ceux-ci ne sont pas correctement passés en revue et l’équipe projet est escomptée les livrer avec les mêmes ressources et dans le même temps que le périmètre original. D’autre part, vous pourriez finir avec un projet qui a des tas de changements dûment considérés et approuvés, mais qui ne finit jamais parce que, chaque fois vous pensez que vous avez fini, un nouveau besoin arrive dans votre boîte à lettre et vous devez faire davantage de changements.

Voici 5 façons d’empêcher la dérive de contenu d’endommager votre projet.

1. Documentez les besoins

Businessman Marking DocumentL’unique et plus importante chose à faire sur votre projet lorsqu’il s’agit de dérive de contenu est de documenter vos besoins. Parlez à toutes les parties prenantes du projet et mettez au point exactement ce qu’elles veulent que le projet réalise. Documentez leurs besoins. Vous aurez à gérer quelques conflits – si une partie prenante veut que le nouveau site Web soit bleu et une autre partie prenante veut du vert, vous aurez besoin de quelqu’un pour arbitrer et rendre une décision finale. De plus, vous devriez prioriser certains des besoins car il peut ne pas être possible de les réaliser tous.

Cela peut prendre du temps de consulter toutes les parties prenantes et d’enregistrer tout ce qu’elles disent. Une fois que vous l’avez fait, capturez tous les besoins dans un document. Alors, vous pouvez ceci partager dans votre espace de stockage de fichiers en ligne pour que tout le monde puisse les consulter facilement.

2. Mettez en place un Processus de Contrôle des Changements
change control

Image courtesy of stockimages / FreeDigitalPhotos.net

Votre documentation des besoins est le point de départ, mais que se passe-t-il quand quelqu’un veut changer quelque chose ? Il est peu réaliste de penser que rien ne changera. Ce que vous visez est un changement managé et contrôlé sur votre projet et pour cela vous avez besoin d’un processus de contrôle des changements.

Un processus de contrôle des changements est très simple. Votre logiciel de management de projet peut avoir la fonctionnalité de gérer des demandes de changement et vous pouvez alors l’utiliser. Essentiellement, quelqu’un suggère un changement, il est passé en revue, approuvé ou rejeté et si approuvé, incorporé ensuite dans le plan de projet.

La mise en place du processus pour votre projet signifie de vraiment réfléchir à qui va passer en revue et approuver les changements. Vous pourriez les revoir avec votre sponsor de projet ou lors d’une réunion d’équipe. Vous n’avez pas besoin de planifier une réunion formelle et récurrente de revue des changements à moins que vous ne pensiez en recevoir énormément et qu’il sera alors plus facile d’être assis avec vos collègues pour les passer en revue tous en même temps.

3. Créez un  échéancier de projet qui soit très clair

gantt chartUtilisez vos besoins pour créer une liste détaillée de tâches. L’échéancier de projet résulte de savoir ce que livrera votre projet, donc il devrait montrer tous les besoins et comment ils seront réalisés, sous forme de tâches et d’activités.

Vous pouvez établir des références croisées entre votre échéancier et votre documentation des besoins, juste être sûr que vous n’avez rien oublié.

4. Vérifiez la définition du contenu avec les parties prenantes
stakeholders grid

Grille des parties prenantes

Il est important aussi de vérifier que vous ayez correctement compris les besoins. Ce que vous pensez que veux le sponsor de projet pourrait en réalité ne pas correspondre exactement à ce qu’il a voulu dire. Souvent les gens se contredisent sans le réaliser, prenez le temps de retourner voir vos sponsors et de partager votre documentation de ses besoins avec eux. Vous pouvez aussi leur montrer votre échéancier de projet et vous assurer que tous les éléments qu’ils se seraient attendus à y voir y sont bien présents dans la liste des tâches.

Vous pouvez aussi faire ceci avec toutes les autres parties prenantes. Prévoyez un peu de temps avec chaque partie prenante et parlez leur précisément de ce que le projet va livrer. Montrez-leur le plan et donnez-leur la chance d’exprimer des remarques. Vous pourriez constater qu’ils changent d’avis, même à cette étape, mais il vaut mieux le savoir maintenant que poursuivre votre projet et constater dans deux ou trois mois qu’ils vous amènent des besoins différents.

Vous pouvez aussi utiliser ces discussions pour parler à votre sponsor et parties prenantes du processus de contrôle des changements. Expliquez comment vous gérerez des changements sur le projet et de quelle approbation vous aurez besoin de leur part pour les accepter. Ceci est un bon moment pour leur rappeler qu’ils peuvent avoir à peu près tout ce qu’ils veulent – s’ils sont préparés à payer pour cela et à autoriser le projet à prendre plus de temps comme ils incluent de nouveaux besoins !

5. Parlez à l’équipe projet

équipe en face à faceSi vos parties prenantes sont satisfaites, vous devriez vous assurer que votre équipe projet l’est aussi. Ils ont besoin de connaître le processus de contrôle des changements et comment il les impactera. Parfois les membres de l’équipe d’équipes projet voudront être vraiment serviables et ils accepteront de changer certaines choses sans utiliser le processus formel. Utilisez votre discussion avec eux pour expliquer qu’ils ne peuvent pas dire oui à un changement sans que ce changement ait été formellement approuvé. S’ils veulent aider une partie prenante, la meilleure chose à faire est d’expliquer le processus et offrir d’aider à documenter la demande de changement.

La dérive de contenu peut être un réel problème sur des projets, particulièrement quand l’équipe et les parties prenantes ne comprennent pas l’impact que les changements peuvent avoir sur les ressources, le budget et les délais. Heureusement, cela ne doit pas être un problème majeur si vous êtes clairs de la portée initiale du projet et managez soigneusement les demandes de changements pendant le cycle de vie de votre projet.

Relisez ce billet sur l’engagement des parties prenantes:
et ceux-ci sur le contrôle du contenu:

November 21 – Webinar (PMI) – Mastering the Project Requirements

19 nov

PMI’s Requirements Management Community of Practice with Michele Maritato

21 November 2013 • 12 – 1 PM EST (6PM CET/France)

 

the level of requirementsEstablishing a proper requirement management process will provide high value to the project. It will give the project the right start; it will lead the project planning towards the creation of value for the business; it will guarantee the voice of the business is heard throughout the project; it will increase the maturity of the organization in creating business value through the projects.

The project manager must first understand that requirements are documented and managed at different levels, involving many stakeholders. And the schema which include Business, Stakeholder, Solution and Transition Requirements should be followed as best practice.

Mastering the project requirements is considered a complex endeavor but in fact it isn’t.

This webinar will present an approach to Requirements Management that includes the following stages: Preparing, Eliciting, Analyzing, Approving and Managing. For each stage the main processes are also described, to suggest the Project Manager the most important topics he should focus his attention. This approach can be used in every project, though the Project Manager must understand that the approach might change throughout all project management process groups: the category of requirements is different at Initiating and Planning, and the weight of each stage might change as well along the project.

Michele Maritato

Michele Maritato

Bringing into the project a professional Requirements Management approach can improve significantly the project results and lead the project in delivering a real business value.

Michele Maritato, MBA, PMP, PMI-RMP, CBAP has over 20 years experience in Project Management and Business Analysis and served as Vice President Organization of the PMI Northern Italy Chapter.

October 22 – Webinar (PMI) – The Impact of Agile/Scrum on Requirements Management

18 oct

PMI’s Requirements Management Community of Practice webinar with Mike Frenette

at 6PM CET/France



scrum methodologie agile

Voici le diagramme du Modèle Scrum

The ground is shifting under the feet of project team members due to the high uptake of Scrum, an Agile framework, in software development projects. Furthermore, this framework is beginning to move into non-development and even non-IT projects.

What is the impact on the collection and management of requirements?

How must the approach to requirements management change to accommodate Agile/Scrum projects?

This presentation will shatter several important requirements paradigms, namely:

  • Requirements must be documented in a Business Requirements Document
  • Requirements must be done at the beginning of a project
  • Requirements are best elicited at the beginning of a project during a requirements phase
  • The analyst defines requirements then moves on to the next project or to another project role .

Through presentation of the theory of Agile/Scrum approaches and discussion of the specific issues that arise for requirements analysts on such projects, participants will gain insight into how they may need to change their approach to requirements management on projects using the Agile/Scrum framework.

votre Projet est-il un succès ? comment jugez-vous si un projet est réussi ?

2 sept

Is Your Project a Success?

http://www.pmhut.com/project-management-foundations-is-your-project-a-success Par Steve Hart

Beaucoup de chefs de projet déclareront fièrement, « Ce projet est un succès majeur : nous avons livré à l’heure et dans le budget ». Quand vous prenez le temps de parler à certains des clients de ces projets, vous entendez une version différente. Dans des nombreux cas, le client décrit un produit livré qui ne répond pas à ses attentes. Dans d’autres cas, le client décrit des processus de projet peu collaboratifs ou peu orientés clients. Je me réfère ici aux cas où vous atteignez finalement les objectifs du projet mais, en fait, des parties prenantes ne sont pas contentes de la façon  dont vous l’obtenez.

S’il y a plus au succès d’un projet que la livraison dans les limites de la triple contrainte (temps, coûts et contenu), comment jugez-vous si un projet est réussi ? Selon mon expérience, ces paramètres sont un bon point de départ, mais elles ne dépeignent pas « l’image totale ». Le succès de projet devrait aussi prendre en considération l’impact que le projet a sur l’organisation, les processus utilisés pour livrer le projet et ce que les clients pensent des résultats du projet.

Ce billet couvre mes idées sur que l’on devrait considérer quand on définit le succès de projet, ainsi que les responsabilités du chef de projet et des responsabilités liées au succès du projet.

Votre réussite passe par la performance de vos projets !

Partenaire de DantotsuPM

À quoi le succès ressemble-t-il ?

Dans le contexte de livraison de projet, le succès est généralement défini en termes d’atteintes d’objectifs définis au préalable. On juge souvent que des projets sont réussi en se basant sur davantage que les buts/objectifs établis dans la charte de projet ou le plan de management de projet et les chefs de projet s’en plaignent. Ci-dessous sont les facteurs que je considère quand j’évalue le succès de projet.

  • Temps et Coût

balance temps vs ressourcesLa date de livraison effective du projet et les coûts sont-ils plus faibles et plus tôt (en prenant en compte l’impact de tous les changements approuvés) ? Le temps et le coût sont les facteurs de succès dont les chefs de projet parlent le plus. Ceux-ci sont les facteurs que les chefs de projet sont directement responsables de manager. De plus, ces facteurs de succès sont relativement faciles à mesurer et à montrer.

  • Contenu

Le projet a-t-il livré ce qui devait être livré ? Le contenu n’est pas limité aux fonctionnalités et fonctions du produit. Le contenu inclut aussi les livrables qui assurent que le produit est correctement implémenté et supporté. J’ai vu mon quota de projets considérés comme des échecs en raison du manque d’attention aux livrables comme la formation, le marketing/adoption du produit et les processus de support.

  • Qualité

cadeauxLe produit livré exécute-t-il la fonction qu’il était sensée exécuter ? Beaucoup d’équipes projet tombent dans le piège de juger la qualité de produit seulement basée sur le nombre de défauts identifiés. Il ne faut qu’un ou deux défauts pour empêcher le produit de fonctionner comme prévu. Les mesures de qualité sur lesquelles on devrait juger du succès devraient être basées sur la capacité à atteindre les objectifs opérationnels (par exemple, le nombre de transactions traitées, le nombre moyen d’appels par heure) et la capacité de répondre aux problèmes liés au produit.

  • Processus

Les processus ont-ils été efficacement utilisés pour livrer les éléments clés du projet ? Les processus comme le contrôle des changements, les communications et le management de ressources peuvent significativement influencer la perception de réussite du projet. Les buts prédéfinis du projet peuvent avoir été achevés, mais s’il a été livré sans collaboration ou avec une flexibilité limitée, les parties prenantes peuvent ne pas voir les résultats de façon positive.

  • Significativité

Le projet a-t-il livré a-t-il eu un impact positif sur l’organisation ? Les projets qui ont peu ou pas d’impact sur l’organisation devraient-ils être considérés comme réussis ? En tant que chef de projet, vous pouvez dire, « ce n’est pas ma faute si le projet n’a pas livré les bénéfices escomptés par l’organisation ». Ceci peut être vrai, cependant j’ai vu beaucoup d’exemples de projets où ce qu’a été livré, ou comment cela a été livré, avait un impact direct sur les bénéfices réalisés. J’ai aussi managé les projets qui ont été livrés en retard ou en dépassement de budget, mais qui ont fourni des bénéfices qui ont de loin dépassé des attentes et ont donc été considérés comme des succès.

  • Parties prenantes

customer satisfactionLes parties prenantes sont-elles satisfaites des résultats du projet ? Les parties prenantes sont les personnes qui ont été impliquées ou ont été impactées par le projet. C’est un problème si l’ensemble de la communauté des parties prenantes, ou de grands segments de la communauté des parties prenantes, ne parlent pas positivement du projet. Le retour d’information peut être une mesure très subjective de succès, mais je crois vraiment que comment les gens « ressentent » le projet est un composant valide du succès du projet. Dans la plupart des cas, des actions spécifiques peuvent être prises pour changer la nature du retour d’information reçu des parties prenantes. Ne prenez pas ce retour d’information à la légère.

6 Façons d’améliorer le succès du projet

Je suis un ferme partisan du fait que le rôle du chef de projet influence significativement le succès du projet. Ci-dessous sont six domaines de bonnes pratiques de management de projet qui ont un impact direct sur le succès du projet.

1. Organisation de Projet

les communications dans l'équipeLa formation de l’équipe projet semble assez basique, mais il est étonnant de voir combien d’équipes projet lancent leur projet sans analyse performante des parties prenantes et définition de l’organisation de projet. Les éléments importants de l’organisation de projet incluent les sponsors de projet, l’équipe principale et comprendre quelles sont les autres parties prenantes clés. Obtenir les « bonnes » personnes sur les « bons » rôles a un impact significatif sur la capacité des équipes projet de répondre aux besoins de l’organisation.

2. Plan de référence de base

En tant que chef de projet on vous présente tout le temps de nouvelles situations (de nouveaux clients et de nouveaux projets) et il est extrêmement important de rapidement donner aux équipes la bonne direction dans le processus de planification. Adapter une approche de planification cohérente de client en client et de projet en projet, améliore significativement les résultats du processus de planification de projet (tant les délais de livraison que la qualité des plans). Des plans de référence forts représentent la fondation d’un processus de livraison fructueux de projet.

3. Mesure de la performance de projet

avis perso KPIsCe domaine de bonnes pratiques implique de garder vos yeux sur les mesures de performance appropriées pour le projet afin d’identifier proactivement des problèmes potentiels et mettre en route l’équipe pour identifier et implémenter des actions rectificatives. L’utilisation efficace de métriques de performance de projet (les KPIs) aide le chef de projet à identifier et implémenter les ajustements d’exécution appropriés au projet avant qu’ils ne deviennent « de gros problèmes » que les parties prenantes ne seraient pas prêt d’oublier.

4. Collaboration

L’engagement actif des parties prenantes dans des activités de projet a un impact significatif sur comment les gens se sentent à la fin du projet. Les chefs de projet améliorent la collaboration sur le projet en facilitant des rencontres d’équipe efficaces, en implémentant des outils et processus de collaboration et fournissant des mises à jour de projet cohérentes et utiles.

5. Gestion du changement

unexpected eventLe changement est un composant inévitable de manager un projet : rien ne se déroule jamais exactement comme planifié. Le chef de projet effectif gère le changement en maintenant l’équilibre approprié entre contrôle et discipline pour réussir à tenir les lignes de référence et la flexibilité à adapter les plans et respecter les attentes des clients. Le niveau de contrôle et de rigueur autour de l’analyse et l’approbation de changements devrait être convenablement « taillé » pour l’organisation et pour le projet.

6. Clôture de projet

À la fin d’un projet, beaucoup de chefs de projet sont occupés à préparer leur projet ou le client suivant et manquent une opportunité majeure de laisser un impact durable sur l’organisation client. La clôture de projet commence effectivement par la fermeture des activités de projet, la validation que tous les livrables produits sont complets et que les problèmes clés sont clos et la transition en souplesse des ressources vers de nouveaux rôles. Le deuxième aspect de ce domaine de bonnes pratiques est de préparer un rapport sur la performance du projet (aussi appelé évaluation post-projet). La création du rapport de performance projet inclut la collecte des retours des parties prenantes principales et l’identification d’actions d’amélioration à implémenter pour terminer ce projet ou pour des projets futurs. Ces actions d’amélioration peuvent influencer significativement la perception des parties prenantes du succès du projet.

Vos commentaires seraient comme toujours fort appréciés. Quelle est votre expérience sur juger du succès de vos projets ?

Campana & Schott

Partenaire de DantotsuPM

June 26 – Webinar (PMI) – Reining in Scope Creep

17 juin

Rope Your Scope: Reining in Scope Creep – Ellen Gottesdiener

stop high interestA PMI Requirements Management Community of Practice Webinar

Problems that result from an unclear, ambiguous, or inaccurate understanding of product scope can permeate and threaten your entire project. This is known as “scope creep”—the unrestrained expansion of requirements as the project proceeds. Scope creep is often cited as a cause of excess costs, late delivery, and dissatisfied customers. Yet discovering requirements is about gaining an ever‐growing understanding of them. So isn’t scope creep to be expected? Can—and should—you identify and limit the scope of a product’s requirements?

Ellen GottesdienerJoin Ellen Gottesdiener, author, facilitator, practitioner, and trainer, as she shares tools and techniques for efficiently and effectively identifying and managing product scope. Learn how you can provide real value to your projects by reducing the risks of scope creep while establishing clear project focus.

View the webinar details and Register for this webinar

tenir précisément les délais du projet n’est pas possible

16 mai

Keeping the Project Timetable Is Not Possible

http://www.pmhut.com/keeping-the-project-timetable-is-not-possible par The Grumpy Project Manager (le chef de projet grognon)

Quelques pensées sur les échéanciers de projet et un peu de Lean Project Management

Projets normaux

Il n’est pas possible de tenir précisément un échéancier de projet, ou du moins la possibilité en est très théorique. Nous clôturons d’habitude un projet quelques heures, jours, semaines, des mois ou années plus tard ou plus tôt que planifié. Il est tout à fait habituel que la différence par rapport au planning varie ±15 %. Ceci est normal, particulièrement quand plusieurs intervenants sont impliqués dans le projet. Ceci est parce que nous avons toujours un peu de ‘bruit statistique’ dans le travail de projet. Des chefs de projet professionnels utilisant des pratiques de management de projet normales ne peuvent pas atteindre de meilleurs résultats. Les choses ne sont pas aussi standardisées que nous l’assumons en préparant un plan théorique de projet. Il n’y a aucun ouvrier standard, les messages sont mal compris ou ignorés, certains trouvent le projet important et d’autres pas, certains ont une motivation plus forte ou plus faible que normal…juste pour mentionner certaines raisons causant la variation. Si les différences entre les échéanciers réels et planifiés sont enregistrées et placées sur un graphique, elles suivent la courbe normale. Elles suivent les lois de nature. Si nous essayons d’améliorer ceci nous empirons d’habitude les choses.

Courbe de distribution normale en rouge

Courbe de distribution normale en rouge

Projets à problèmes

gros problemeSi la variance par rapport au plan dépasse 15 % nous avons des problèmes sur le projet. Désormais, ceci n’est plus normal; quelque chose a mal tourné. Quelques raisons peuvent habituellement être identifiées. La première est la compétence; l’organisation, l’équipe projet ou une partie des membres ne sont pas tout simplement assez habiles pour planifier ou exécuter le projet. La deuxième est une combinaison d’importance, de motivation, de préparation et d’acceptation des objectifs; ce n’est pas à propos d’à quel point le projet est défini comme important, mais comment les parties prenantes le comprennent. Le troisième facteur est la gestion du contenu, un périmètre vague ou des changements non contrôlés sur la portée par rapport au contenu agréé.

Campana & Schott

Partenaire de DantotsuPM

Les suspects habituels

suspects potentielsComme on connaît les suspects usuels qu’il est possible de faire quelque chose avec eux. Par exemple, nous pouvons demander à toutes les parties prenantes appropriées avant qu’un projet ne commence ce qu’elles pensent du projet. Le trouvent-elles important, comprennent-elles les objectifs et les acceptent-elles, sont-elles ont motivées pour soutenir le projet, sont-elles prêtes à s’engage sur le projet et mettre en œuvre les livrables finaux. Des enquêtes en ligne simples peuvent être utilisées pour ceci. En conséquence, nous saurons s’il y a un écart entre la compréhension des initiateurs et des parties prenantes. Si les initiateurs trouvent un projet important, mais pas les parties prenantes, nous aurons des problèmes pendant l’exécution. En étudiant à l’avance les suspects habituels, nous pouvons considérablement améliorer la probabilité de succès des projets.

Projets Lean

competingIl est bien sûr possible de limiter à 15% la variance dans les échéanciers de projet. Cependant, ceci exige des actions spécifiques dans l’organisation. En outre, si des partenariats ou de l’externalisation sont nécessaires, Ils devront être particulièrement compétents dans le travail de projet. À cause de ceci, il vaut mieux en premier lieu se concentrer sur la sélection des bons projets. Sélectionner les bons projets est plus important que de rester sous les 15% de variance. La sélection des bons projets est aussi la première façon de rester sous ce seuil; les bons projets sont importants et motivent souvent les membres et les supporters. L’étape suivante serait de réduire la quantité de projets. Avoir deux projets particulièrement importants en même temps les fera rivaliser et tous les deux perdront.

Épilogue

Si la différence entre des échéanciers réels et planifiés est continuellement supérieure à 15%, des actions alors spéciales devraient être prises pour améliorer ceci avant de faire tout autre chose. Les suspects usuels devraient être étudiés et des actions d’amélioration prises en fonction des résultats. La compétence organisationnelle est la zone de problèmes la plus difficile : l’admettre et s’améliorer.

Quand la différence entre les échéanciers réels et planifiés est continuellement inférieure à 15%, les efforts pour essayer de réduire ces écarts devraient être arrêtés et le focus mis sur la sélection des bons projets. En outre, une recherche active peut être utilisée pour étudier les suspects habituels avant le lancement d’un projet pour garder la variance dans les ±15%.

Votre réussite passe par la performance de vos projets !

Partenaire de DantotsuPM

LoL Scrum-Master en cette journée du rire :-))

5 mai

Bonjour, je pense que cette vidéo humoristique sur Scrum et plus particulièrement sur le rôle de ScrumMaster vous fera sourire.

Bien que traités sous un angle amusant, les problèmes abordés sont ceux rencontrés par bien des équipes Agile.

  • Membre de l’équipe systématiquement en retard au Daily Stand-Up
  • « Scope Creep » avec des utilisateurs qui ne respectent pas le rôle du Product Owner
  • Quand « Done » est-il réellement « Done »?

Postez vos commentaires après avoir essayé ces techniques vigoureuses.

votre premier projet, c’est simple comme 1-2-3 avec Prince2 selon Jeff Ball

14 mar

votre premier projet PRINCE2 commence par 1-2-3

Comment démarrer votre premier projet PRINCE2 en 3 étapes simples.

QRP International France

Partenaire de DantotsuPM

téléchargez le document PDF original à partir du site de QRP International

Vous avez suivi une formation PRINCE2, vous avez passé l’examen, vous êtes maintenant de retour à votre bureau, vous rouvrez le manuel de 350 pages, 19 chapitres et 26 documents …

Oui mais …. Par où commencer ?
… Simplifions les choses en 3 étapes !

1. Rédiger l’Exposé de Projet et faites-le approuver par votre exécutif

Comme son nom l’indique, l’Exposé de Projet est un document de synthèse. Il doit être facile à lire. Le manuel PRINCE2 suggère un modèle pour ce document : cependant, mieux vaut privilégier la lisibilité et la clarté plutôt que le formalisme et les détails.

L’Exposé doit contenir la structure organisationnelle du projet. Vous êtes le chef de projet, et vous avez besoin d’un Exécutif. C’est VITAL, le minimum vital. Sans Exécutif vous n’utilisez pas PRINCE2. L’Exécutif va assumer la responsabilité du projet. Vous allez exécuter en son nom le projet.

L’Exposé doit aussi contenir une description du produit du projet, votre livrable final. C’est important  de le documenter, c’est ce qui va définir votre périmètre. Le manuel PRINCE2 nous dit que c’est un document séparé mais vous pouvez l’inclure comme un paragraphe de votre Exposé.

Afin de définir correctement votre produit du projet, vous devez comprendre qui est votre client ou utilisateur (celui-ci peut être un client interne ou externe). Vous devez discuter de vos livrables avec votre client, pour comprendre leur besoin. L’Exposé de Projet doit inclure les exigences qualité du client et les critères d’acceptation.

Une fois l’Exposé rédigé, l’Exécutif doit le valider, vous ne pouvez pas continuer sans cela.

2. Créer une Structure de Décomposition du Produit et en obtenir l’approbation

Car-WBS

La structure de Décomposition du Produit (SDP) est un excellent moyen de comprendre ce qui doit être produit. Le SDP commence avec votre produit du projet, votre livrable final. Le SDP va vous donner plus de détails, 15 ou 20 livrables en tout.

Le moyen le plus simple de créer un SDP est de coller des post-it sur un tableau. Par ce biais il est facile de remodeler le SDP au fur et à mesure que les idées émergent. De manière idéale, faites-vous appuyer d’un collègue ou deux pour garantir une vision plus large. Une fois cela réalisé, convertissez les post-it en version électronique en utilisant un outil tel que Visio ou Powerpoint. C’est important de créer le SDP avant de commencer toute planification. Pour PRINCE2, le SDP est la première étape de planification.

Si vous utilisez un outil de planification, tel que MS Projet ou même Excel, vous devez créer d’abord votre SDP et la faire approuver avant de commencer le travail avec ces outils. Votre PC doit être éteint !

Vous devez passer en revue la première version avec les acteurs clés : L’Exécutif, le client ou l’utilisateur et avec les chefs d’équipe qui vont produire la solution. Une fois approuvée vous pouvez créer le plan de projet autour des 15-20 livrables de votre SDP.

3. Créer un Cas d’Affaire en collaboration avec votre Exécutif.

Le cas d’affaire fourni la justification du projet. Il explique les ressources que le projet va utiliser et les compare avec les bénéfices escomptés. C’est un document important, cela dit, il doit être simple et court. Le problème avec le Cas d’Affaire est que l’on ne sait jamais quel niveau de détail est approprié. Votre Exécutif va vous guider sur ce point. N’ajoutez pas de détails superflus (si votre société n’a pas besoin d’exprimer les besoins en termes financiers, ne le faites pas).

balance temps vs ressourcesCommencez avec un résumé de votre besoin en ressources, et les bénéfices escomptés – pour de nombreux projets, c’est suffisant.

  • Les ressources sont habituellement des personnes et/ou de l’argent. Vous devez comprendre quels types de ressources sont nécessaires. (Par exemple, vous avez besoins de développeurs et de testeurs et de l’argent pour acheter les équipements).
  • La justification se base sur les bénéfices – obtenez les informations sur les bénéfices avec votre Exécutif. Tous les deux, vous devez comprendre les types de bénéfices que votre projet va générer (par exemple, réduction des coûts de production, de maintenance).

Une fois que vous avez un résumé vous pouvez détailler davantage, seulement si nécessaire. Il faudra peut-être convertir les ressources et les bénéfices en termes financiers. Vous aurez besoin probablement d’un calendrier et aussi d’un calcul financier complexe tel que la valeur actualisée nette. En tous les cas, simplifiez toujours les choses, n’effectuez pas le travail si ce n’est pas nécessaire.

3 poissons qui sortent du commun

1,2,3…

En trois étapes simples, on a les fondements de notre DIP (Documentation d’Initialisation de Projet).

Les trois piliers clés du DIP sont : l’Exposé de Projet, le Plan de Projet et le Cas d’Affaire. Ces trois étapes nous permettent de créer ces trois piliers. Voici la manière de mettre en pratique les concepts de votre formation PRINCE2 en trois étapes simples.

© Copyright QRP International 2013. Reproduction in full or part is prohibited without prior consent from QRP International.

APMG International Showcase

Suivre

Recevez les nouvelles publications par mail.

Rejoignez 1 131 autres abonnés

%d blogueurs aiment cette page :