Archives de Tag: scope

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

priorisation des besoins sur un projet Agile

30 juin

Prioritizing Agile Project Requirements

http://blogs.pmi.org/blog/voices_on_project_management/2011/04/prioritizing-agile-project-req.html

par Bill Krebs

Dans la gestion de projet Agile, nous devons prioriser une liste de demandes pour la planification de version, d’itération et l’insertion de nouveaux besoins ou exigences. Mais il y a plusieurs techniques pour le faire.

Une des méthodes les plus populaires pour déterminer la priorité des demandes est l’approche dite “MoSCoW”. Cela signifie ‘ Must (Doit), Should (Pourrait), Could (Devrait), Won’t (ne fera pas). ‘ Le seul problème avec cette méthode est que d’habitude tout est un Must, ce qui ne permet pas une planification appropriée parce que les besoins ne sont pas nécessairement placés dans leur ordre de priorité.

modèle de KanoUne autre méthode est le modèle de Kano, développé par le Professeur Noriaki Kano, qui s’efforce de satisfaire les exigences et de faire plaisir aux clients. Ce modèle dispose de quatre composants :

• Must haves (doit avoir) sont des éléments sans lesquels on ne peut livrer le produit.
• Dissatisfiers (générateurs d’insatisfaction) sont des choses que le produit ne doit pas inclure.
• Satisfiers (générateurs de satisfaction) incluent besoins pour lesquels plus vous en avez mieux le produit sera perçu. Comme un catalogue commercial dans lequel chaque fonctionnalité ajoute progressivement de la valeur.
• Delighters (générateurs de plaisir) amènent le produit plus loin que simplement répondre aux exigences vers l’augmentation de la satisfaction client et la recommandation par le client.

Plusieurs modèles de priorisation réunissent deux variables dans un tableau pondéré : fonctionnalités et clients. Chaque fonctionnalité est pondérée par sa valeur pour chaque client. La somme des poids multipliés par le score permet de voir quelles fonctionnalités sont en général les plus utiles pour un jeu de clients exigeants.

Quel que soit la technique utilisée, votre liste d’exigences de projet doit être triée de la plus grande à la plus faible valeur.

Quelles techniques utilisez-vous pour prioriser les besoins ?

le site de microsoft projet en français

Partenaire de DantotsuPM

webinaires (webinars) gratuits en anglais sur le management du changement

5 août

Marc Bonnemains du PMI Ile de France nous indique de nouveaux Webinars sur la gestion des changements.

Une série de webinars gratuits en anglais sur le management du changement donnés par le Change Management Learning Center. Ces webinars donnent lieu à des PDUs en catégorie 3 pour les certifiés PMI.

Lien : http://www.change-management.com/webinars.htm

Mauvaise définition des exigences ? En réalité, c’est votre faute

20 juil

Voici un article de Jesse Fewell qui m’a paru intéressant: “Bad Requirements? Actually, That’s Your Fault”

Je suis fatigué des chefs de projet qui se plaignent de la mauvaise qualité de la définition des exigences. La vérité est que personne ne devrait s’en étonner. Dans la recherche comme dans les désastres très visibles, nous entendons dire que des exigences incorrectes et la mauvaise gestion du contenu sont des raisons principales d’échec des projets. Si nous savons que c’est un problème commun de notre profession, pourquoi continuons-nous stupidement à répéter ce qui ne marche pas ? Je voudrais partager quelques suggestions pour nous empêcher de trébucher sur ces mêmes erreurs :

Abandonnez l’illusion d’obtenir des exigences complètes.

Il y a toujours une dépendance manquée, une partie prenante que nous n’avons pas interviewée, une nuance cachée, ou une chose que nous regretterons de n’avoir pas su. Ne tombez pas dans le piège de penser que davantage est toujours mieux ou vous ne commencerez jamais.

Supposez toujours que les besoins initiaux sont faux.

Parfois la définition du contenu est trop inclinée vers une partie prenante ou n’a pas été correctement examinée de près. Parfois la plus grande partie des exigences sont en réalité seulement des choses “agréables-à-avoir”. De nos jours, on s’attend à ce que le chef de projet ait le bon sens organisationnel et les compétences de facilitation pour arriver à la cause racine de ces problèmes. Pour vous assurer que vous donnez les bonnes priorités au bon moment, prenez la déclaration de portée initiale comme un point de départ, travaillez ensuite avec le sponsor pour l’affiner.

Acceptez que tout besoin change.

La culture de management de projet traditionnelle décrit le changement comme un mal nécessaire, comme les lois : si tout le monde faisait tout correctement, nous n’aurions pas besoin d’elles. Pour atténuer “le risque” lié au changement, nous mettons en place des processus de demande de changement intimidants et des pénalités financières. Mais que se passe-t-il si ce que vous avez développé pendant les deux dernières années n’est plus approprié pour votre marché ? Y-a-t-il un sens à continuer à faire payer votre sponsor pour ce qui est maintenant essentiellement un produit inutile ? Pas selon moi. Si nous acceptons que les exigences soient incomplètes et incorrectes, nous devons les modifier pour refléter la réalité. En effet, le corpus de connaissance en management de projet (PMBOK ®) énonce : “à cause du potentiel de changement, le plan de gestion de projet est itératif et passe par l’élaboration progressive tout au long du cycle de vie du projet.”

Simplifiez votre approche de gestion des modifications.

Les chefs de projet agiles embrassent explicitement la valeur de bien répondre aux changements et instituent une politique de projet en conséquence. Commencez par mettre en œuvre une structure de contrat qui supporte les changements autorisés plutôt que les pénalise. Au début de chaque itération, organisez une revue de haut niveau mais minutieuse des priorités de contenu. Si votre sponsor a des difficultés à déterminer les priorités, assistez-le en lui indiquant les différences. Une fois que les changements sont acceptés, redéfinissez les références de la valeur acquise au moins toutes les trois à quatre itérations pour qu’elles correspondent au dernier périmètre. Et pendant que vous y êtes, communiquez proactivement la dernière définition du contenu à toutes les parties prenantes.

Si vous trouvez systématiquement que la définition des exigences vous amènent des problèmes, faites quelque chose. C’est votre responsabilité de chef de projet que d’être adaptable aux besoins de votre sponsor. Arrêtez de prendre les exigences pour acquises et commencer à équiper votre sponsor pour qu’il fasse les bons choix de contenu.

webinaires (webinars) gratuits en anglais sur la gestion des exigences

14 juil

Marc Bonnemains du PMI Ile de France nous suggère de consulter les webinars suivants:

http://www.iag.biz/resources/webinars/on-demand-webinars.html

Merci Marc pour ces pointeurs fort utiles.

IAG ConsultingRegister to view any of these recorded events:

5 Things You Must Know About Requirements Planning (1 PDU)
Requirements Planning adds incredible value to the requirements process. More than simply creating another “work breakdown structure” document, this is an opportunity to address risks proactively and gain better stakeholder participation.  This session demonstrates how every component of a requirements plan adds value.

Learning Objectives
1. Illustrate the pitfalls of traditional approaches to Requirements Planning
2. Deliver guidelines for making Requirements Planning a value-add activity
3. Know what material must be present in a high quality requirements planning document

Harmonizing Agility & Discipline:  Balancing Warring Methodologies and Achieving Success (1 PDU)
This session demystifies the wide range of agile and more traditional requirements and development methodologies.  The session looks at the strengths and weaknesses of each approach and gives prescriptive guidelines to requirements leadership looking to improve results by striking a better balance between agile and disciplined practices.  This session refocused the agility versus discipline dialogue:  it is not that these practices are mutually exclusive – the real issue is to look at your current circumstances and find the right balance to maximize success.

Learning Objectives
1. Look at the structure of agility and discipline-based methods
2. Provide guidelines for adding agile practices to traditional software development environments
3. Provide guidelines for reapplying traditional development practices to the agile software development environment

Managing Requirements Operational Excellence:  A Framework for Accelerating Organizational Development (1 PDU)
This session is for business analyst leadership and development executive looking to make long term, systematic improvement to their business analyst organization.  IAG will draw from its project experience with over 700 customers to baseline organizations, assess the value of improvement, and determine the action plan for success.

Learning Objectives:
1. How do you assess the maturity of an analyst organization?
2. Where do you focus for improvement?
3. What implementation guidelines should be used to enhance success?

Predicting Project Outcome – 1 PDU
This is an advanced webinar for senior project managers and giving them the facts to predict the outcome of their project based on the quality of the business requirements process and deliverables.  Findings are based on extensive research, and a predictive risk assessment model is presented.  The presentation also shows actions that project managers can take to mitigate risk should requirements issues be found.

Optimizing Requirements Discovery – 1 PDU
Why should it take months to determine project scope and gather requirements? Register now to look at the underlying problems that impede the collection of business requirements and make projects less successful. Within this session, participants get new data from IAG’s research that quantifies the cost of poor requirements and shows the impact on companies of a strong, repeatable process. Attendees will see some of the techniques IAG uses in our methodology and proven successful on over 1,000 engagements. Finally, making quantum organization improvement is our specialty and this session will review the levers of change that IAG focuses on to deliver excellent results.

Outsourcing Requirements Discovery – 1 PDU
This session is for project managers that sometimes need to contract externally for requirements discovery services in order to make their project a success.  This session shares hard facts, case studies, and a wealth of experience in successful – and not so successful – contracting approaches for the senior project manager.  This session covers engagement models that drive value, identifying red flags in the contracting or managing stages of working with vendors, and the targets for vendor performance  Supercharging a project by accelerating the requirements discovery phase is a solid strategy – but how do you ensure the company will get solid business value from the activity?

Collect Requirements: Action Steps That Get Results - 2 PDU
This is a fast paced session for Project Managers, Analysts, and Development Leadership of all skill levels and experience to overview how to collect requirements efficiently. Why take the session: Project Managers need to know what PMBOK® Guide – Fourth Edition “Collect Requirements” has in expected outputs. Business Analysts need superior techniques for engaging stakeholders. Development Leadership wants to get transparency into the process of requirements, and know what value this brings to the organization. This session wraps these three critical objectives into an intense, two hour session.

Learning Objectives:
1. When should the requirements be defined? How and by whom?
2. How do I keep the clients on track and the requirements aligned with the agreed objectives?
3. What is the difference between a use case and a requirement?

7 Secrets to Defining Requirements for Package Software Selection - 2 PDU
This two hour on-line course will provide Business Analysts and Project Managers with essential techniques and specific guidelines for gathering and defining the right kind of requirements needed for inclusion in an RFP for the selection of a vendor for application software. In order for Business Analyst’s and Project Manager’s to perform effective and efficient vendor evaluation, the business requirements need to be appropriately defined and structured. If you have struggled strategies for commercial-off-the-shelf software acquisition, what level of detail is needed in an RFP, when and how to involve the vendors, what research is required, and what templates to use — then spend two hours with us to help you set the right path for success with your next COTS project.

Learning Objectives
1. How are the methods for defining requirements for a software product different than for custom developed solution?
2. How much detail is needed for an RFP?  How do I know what to exclude and include?
3. How do we accommodate changing requirements? When do we hold vendor demonstrations?

6 Steps to Prioritizing Your Business Requirements - 2 PDU
This two-hour webinar for project managers and business analysts gets right to the point and covers the essential steps for prioritizing business requirements – a process based on industry best practices ranging from QFD, MoSCoW and others – and employing IAG’s experience and proven techniques for practical requirements prioritization. This webinar will explain why prioritization is important, when it is needed and when it isn’t, when it should be done, what different strategies could be used and what techniques work best. Participants will learn a practical process that is adaptable to various types of projects from large to small and a variety of environments from agile to waterfall. It will provide Project Managers and Business Analysts with a clear understanding of what they need to know, and what they need to do, to easily and effectively prioritize the product requirements for their next project.

Learning Objectives
1. The Most Effective Prioritization Strategies
2. Different Prioritization Techniques, Why Prioritize?, When to Prioritize Knowing , What to Prioritize
3. The Six Steps to Prioritizing Business Requirements
4. Key Requirements Prioritization Success Factors
5. Facilitating Requirements Prioritization Meetings, Rating Facilitation Methods

Suivre

Get every new post delivered to your Inbox.

Joignez-vous à 216 followers