la structure de découpage du projet (Work Breakdown Structure: WBS) par Philip Diab (R)

A lire sur:  http://leblogdumanagementdeprojet.com/2013/07/30/repost-2011-la-structure-de-decoupage-du-projet-work-breakdown-structure-wbs-par-philip-diab/

Si je devais identifier un seul outil/méthode/processus qu’il faut maîtriser parfaitement pour les chefs de projet, ce serait la structure de découpage du projet (WBS). Encore, je suis toujours stupéfié que dans certains des ateliers de travail poussés que je conduis sur la gestion de projet très peu de praticiens comprennent ce qu’est un WBS et comment développer un bon WBS qui aidera dans la planification de projet.
Heureusement, cette semaine j’enseigne « les essentiels du management de projet » donc mes attentes du savoir des participants sur le WBS sont assez faibles. C’est l’un des sujets que j’essaye de ne pas couvrir à toute vitesse, même si cela signifie que je déborde le temps qui lui est imparti dans l’agenda de l’atelier. L’endroit où je commence d’habitude est par la définition standard du WBS selon le PMBOK, qui expose :

“A deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables.  It organizes and defines the total scope of the project.”

Dans la communauté de management de projet il y a deux vues du développement de WBS. Un groupe se concentre sur l’identification des tâches qui sont nécessaires à accomplir sur le projet. Ce que cela signifie est qu’ils aiment identifier tous "les verbes" associés au projet. Dans ce cas, l’argument est qu’en identifiant les activités, on est capable de produire l’échéancier à partir du WBS. Dans certains outils de planification, il y a même une option pour produire une vue imagée de l’échéancier comme un WBS.
Il y a un autre groupe qui est concentré sur l’identification de tous les livrables qui doivent être produits par l’équipe projet. Ce que cela signifie est qu’ils identifient tous "les noms" associés au projet. Je suis un partisan de cette dernière vue. En travaillant sur la définition de tous les livrables, nous sommes capables de produire une liste des éléments à fournir par le projet. L’identification des tâches, l’évaluation et la planification sont donnent en effet des activités qui suivent mais à mon avis ne font pas partie du développement du WBS.

Voici quelques bons trucs qui m’ont servi bien dans le développement du WBS

• Concentrez-vous le quoi pas le comment. ”Qu’essayons-nous de faire, pas comment ?”
• Le WBS est une activité d’équipe, il devrait impliquer les parties prenantes du projet, pas seulement le chef de projet.
• Donnez l’occasion à l’équipe de « remuer ses méninges » (brainstorm) en utilisant des post-it pour qu’ils puissent travailler tant de haut en bas que de bas en haut. Cela permettra de prendre en compte de multiples styles de travail. Ceux qui aiment commencer par la vue d’ensemble et ceux qui aiment les détails peuvent être satisfaits de cette réflexion en commun d’une façon qui les met à l’aise.
• “Les mauvaises idées” devraient être encouragées pendant le remue-méninge et prises en compte lors de regroupements de livrables plus tard. L’avantage d’identifier un livrable qui est en dehors du périmètre projet est que cela peut être parqué sur une feuille séparée et documenté plus tard en tant que tel.
• Assurez-vous de documenter les suppositions faites par l’équipe et d’utiliser ensuite ces suppositions comme une entrée potentielle dans l’identification des risques.
• Ne vous contraignez pas à essayer de fournir les éléments dans l’ordre, cela viendra plus tard.
• Assurez-vous que l’équipe documente les livrables internes et externes. Chez IBM nous utilisions le terme « produit de travail » pour des livrables internes pour les distinguer des livrables qui entrent dans un énoncé des travaux (statement of work).
• Capturez les deux types de livrables. Beaucoup d’équipes oublient souvent qu’une une charte de projet et un plan projet sont en réalité des livrables qui devraient apparaître dans le WBS.
• Utilisez le développement du WBS comme une opportunité de construction d’équipe en rassemblant les membres du projet et en accélérant les étapes de développement d’équipe.
• Rappelez-vous la règle de 80 heures par lot de travail. À un bas niveau dans le WBS, on trouve les lots de travail. Ces lots de travail sont des livrables composés de tâches dont la somme devrait atteindre environ 80 heures d’effort.

Les bénéfices et utilisations du WBS sont multiples.

En identifiant la portée totale du projet par une décomposition par livrables, le WBS aide l’équipe de projet à réaliser les choses suivantes :

• Comprendre ce qui est "à l’intérieur" et ce qui est "à l’extérieur" du périmètre du projet. Ce qui n’est pas listé, est en dehors. Ce processus peut permettre l’équipe de projet de documenter qu’un livrable donné est à l’extérieur du périmètre.
• Envisagez les secteurs potentiels de risque, en vous servant des suppositions documentées.
• Construisez une fondation pour développer une référence de base solide de projet et chaque lot de travail peut être utilisé pour identifier des tâches principales selon règle des 80 heures.
• Communiquez avec des parties prenantes sur les besoins potentiels qui pourraient être demandés en croisant exigences et livrables.
• Établissez une responsabilité claire pour les lots de travail et assignez des propriétaires/champions.

Il y a beaucoup d’autres trucs et bénéfices pour le WBS, tels que le système de codage qui peut être utilisé ou comment se servir du WBS pendant la phase d’exécution et dans le processus de contrôle. Même si chacun de ceux-ci est une considération importante, mon focus pour ce billet a été en utilisation du WBS comme un robuste point d’ancrage pour l’équipe pendant le processus de planification.
Je conclurai en soulignant qu’un bon WBS peut en effet être un facteur différenciant entre un projet réussi et un échec. Ceux qui ne sont pas familiers avec le WBS ou ne savent pas comment le créer doivent passer du temps à parcourir le PMBOK Guide et autres livres qui contiennent les appropriées.

5 Tips For Great Task Lists

A lire sur:  ProjectManager.com

Task lists are the foundation of your project plan. Without a good task list, it will be much harder to produce your project schedule. After all, how will you know what to do? Every project should start out with a comprehensive task list.

Here are our 5 tips for creating stellar task lists on your projects.

Tip 1: Work with your team
You cannot create a full task list for your project by yourself, so enlist the help of your project team. Schedule some time to sit together and brainstorm ideas as your colleagues will no doubt come up with different tasks to include on the project list to add to the ones you have already thought of. At this stage, simply record everything, either on paper or directly into your project management software. Try to get down as much detail as you can, but don't worry too much about allocating tasks to people right now. You can do that later, again with input from your subject matter experts.

Tip 2: Structure your list
When you have a complete task list, upload it to your project software if you haven't already so that you can start working with it. Group together tasks that are related and add some sub-headings to make it easier to navigate through the list. Having similar tasks logically grouped is the next stage to creating a comprehensive project plan. All of this gives you the chance to create some structure to your list so that you can easily find individual tasks and your list makes sense when you review it.

Tip 3: Prioritize tasks
A great task list will instantly show you the most important tasks. It doesn't matter if you are documenting the activities you need to include on your project schedule or your daily To Do list, some tasks will have a higher priority than others. Use your task management tools to highlight the most important tasks, perhaps by using a different color, making the font bold or adding some stars next to those items. You'll instantly be able to see your priorities for the day.

Tip 4: Store your task list centrally
It's so easy to get confused about your priorities and lose the complete picture if you have tasks written on sticky notes, on your calendar, in your project notebook or on email. Using the task management features in ProjectManager.com makes it easy to keep all your tasks in order, in one central location.

This is also a great tip if you are sharing your task list with the rest of the project team. It can save you a lot of time if you all work off one list, and you'll never get confused about what is on the list and what isn't! When it is all in one place, everyone shares the same, comprehensive view of the work that needs to be done.

Tip 5: Mark tasks as complete
What is the best thing about task lists? Marking the tasks as complete, of course! There's nothing more satisfying than ticking off a task that you have finished. Whether you draw a line through it, tick a box, delete a row in your software or any other way of marking your progress, make sure that you go back to your list and celebrate each completed task (and therefore your progress towards a bigger project objective) by crossing it off your list. Then you can move on to the next task!

Social task management vs. project management tools for your SMB

A lire sur:  http://www.techrepublic.com/blog/it-consultant/social-task-management-vs-project-management-tools-for-your-smb/

By Will Kelly in IT Consultant, July 24, 2013, 6:23 AM // willkelly

If your SMB is trying to determine whether it needs a social task management solution and a project management platform, find out what each option offers.

Social task management applications, in particular Asana, Producteev, and Do.com, are getting a lot of well-deserved attention lately. These free cloud platforms are bringing order to project teams in midsize to large enterprises. Introducing one of these applications to your small to medium business (SMB) is a key first step to getting a basic project management framework in place.

Choosing a social task management solution

Asana, Producteev, and Do.com bring the traditional task list or to-do list to the cloud. As an entry-level tool, social task management applications offer SMBs an option to centralize tasks for the entire organization and provide a familiar format for the widest audience of users. Any authorized user can then interact with workspaces, projects, and task lists in a rather free form manner. If your SMB is struggling to stay organized on projects and other initiatives, going with a social task management platform is a definite first step to achieving a project focus.
Some common features of social task management solutions include:

• Secure workspaces that you can lock down to teams or departments
• Projects (lists of task items) that reside in the secure workspaces
• Limited scheduling tools (date, time, and reminder) for tasks
• Audit trail for tasks (date and time added and then modified by the assignee)
• Tagging of tasks
• Sharing of tasks and task lists
• Favorite particular task(s) in a project
• Comments and feedback on tasks and task list
• Email reminders about tasks
• Integration with Google Calendar

These features can give everybody in an SMB a singular view into what's going on across different projects and business activities. Here are reasons why a social task management solution might be the right choice for your SMB:

• Quick and dirty tool for centralizing all project and business tasks
• Little or no budget for a task management solution
• Schedule tracking is still ad hoc and not an issue yet
• Resource management over people is not yet a consideration
• Project management is yet to be part of a job description

While each of the major social task management platforms is promising to remain free, each one is but an introduction to their company's fee-based premium services or products. The Asana product roadmap includes premium services. Jive now owns Producteev, with plans to use it for attracting new customers. Likewise, Salesforce owns Do.com and now offers Premium Services and uses Do.com integration with other cloud applications as part of its Do More with Do strategy.

Choosing a project management solution

The prevailing winds of SMB growth, project failures, and the need for tighter internal controls over project schedules, budgets, and staff mean an SMB may reach a point when it's time to choose a true project management platform to either augment or replace social task management inside their organization.
The Software as a Service (SaaS)-based project management platforms available aren't just for large enterprises; in fact, project management solutions like LiquidPlanner, Viewpath, and Teambox can point to SMB customers where their product plays a central role in running projects and business operations. As a central hub, a SaaS project management solution can offer an SMB the following:

• One view over project schedules for managers and team members
• Notifications, commenting, and audit trail over tasks
• Time tracking and approval

Any concerns about a SaaS-based project management solution sapping the free flow creativity of your startup or SMB should be put by the wayside, because the current generation of these tools require remarkably little administration and offer a true convergence of collaboration and project management features. Your entire SMB (rather than just a formally trained project manager) can interact with a SaaS-based project management platform.
The choice to augment an in-place social task management solution with a project management solution (or just migrate entirely) comes down to these factors:

• Requirement for multiple views into project tasks, scheduling, and resource information (Gantt charts, workload, and calendar)
• Progress and schedule tracking are becoming a necessity
• Resource pooling and allocation are becoming a necessity
• Time logging and time tracking of tasks
• Project budget controls

Coexistence or one platform?

The possibility of a social task management and a project management solution coexisting depends on your SMB's needs. However, I encourage you to keep transparency in mind, because task management and many of the same features your SMB enjoys with social task management tools are available in LiquidPlanner, Wrike, Teambox, and other project management platforms.
For insight into how an SMB found transparency improvements in a single project management platform, read the case study I wrote for ZDNet (TechRepublic's sister site) about how Duxter streamlines collaboration and project management with Teambox.

What did your SMB choose?

Has your SMB had to choose between social task management and project management? If so, let us know what you decided and how that's working out by posting your comments in the discussion.

Understand These Three Estimating Concepts

A lire sur:  Method123

Estimate in Phases

One of the most difficult aspects of planning projects is the estimating process. It can be hard to know exactly what work will be needed in the distant future. It can be difficult to define and estimate work that will be done three months from now. It's harder to estimate six months in the future. Nine months is even harder. There is more and more estimating uncertainty associated with work that is farther and farther out in the future.

A good approach for larger projects is to break the work into a series of smaller projects, each of which can be planned, estimated and managed separately with a much higher likelihood of success. From an estimating perspective, the closest project can be estimated more precisely, with the subsequent projects estimated with a higher level of uncertainty. When one project completes, the next project can be estimated with a higher degree of confidence, with estimates refined for the remaining projects. This technique also provides checkpoints at the end of each project so that the entire initiative can be revalidated based on current estimates to ensure that it is still viable and worth continuing.

Estimate Fixed Costs and Variable Costs

You may hear the terms fixed and variable cost when you are estimating the cost of a project. Variable costs are those that change relative to how many units are being used. An obvious variable cost on a project is contract labor. The more hours you use from a contactor, the more the cost to the project. The cost of contract labor is variable depending on the number of hours worked.

Fixed costs are those that are basically the same for the project regardless of the resources being used. For instance, if you were building a house, the cost of the lot would be fixed and would not change based on the size of the house you built. Similarly, if you outsource part of a project to a third party for a fixed price, it becomes a fixed cost to the project as well. Even if the work takes longer or shorter than estimated, your project cost should still be the agreed upon fixed cost.

Estimate Time-Constrained and Resource-Constrained Activities

Activities can be classified as time or resource-constrained based on whether the duration can change if more resources are applied. An activity is resource-constrained if the duration changes based on the number of resources applied. For instance, you might estimate that it will take 80 hours for one person to build a roof on top of a house. If the person worked forty hours per week, it would take two weeks to complete the job. If you applied two people to the job, the effort is still be 200 total effort hours, but the job would only take one week to complete.

On the other hand, if an activity is time-constrained, the duration remains the same regardless of the number of resources applied. For example, lets say one person attends a three-day class. If you send two people to the class, the class does not get shorter; it still takes three days. Likewise, the time it takes for concrete to dry, or to mail a letter, is not impacted by the number of people involved. They just take a certain amount of time. If you find that applying resources has no impact on the project duration (or very little impact), then the activity is time-constrained. 

Techniques to Elicit Requirements

A lire sur:  Tenstep

Requirements are usually gathered in two places during a traditional project. High-level requirements help you complete a Project Charter. Detailed requirements are gathered during an Analysis Phase. The detailed requirements help you understand how to design and build the solution. 

The TenStep requirements gathering model has four steps - elicitation, validation, specification and verification.

The elicitation step is where the high-level requirements are gathered. To elicit accurate requirements, the project manager must ask the right kind of questions and then listen carefully to the answers. Gathering requirements through an interview process is probably the most common technique. However, there are many techniques for gathering requirements, and in many projects the team will need to utilize a number of them instead of, or in addition to, interviewing. For instance, if you want to gather input from 100 users, you probably will not be able to talk to each one of them independently. In fact, if you did, you would find that you are not receiving very much information after you have finished the first couple. A better, faster and cheaper approach might be to interview a small number of people in this group and then send surveys to the rest.

There are a number of techniques for eliciting requirements, and your project may need to use multiple techniques depending on the circumstances. 

• One-on-one interviews. The most common technique for gathering requirements is to sit down with the clients and ask them what they need. The discussion should be planned out ahead of time based on the type of requirements you are looking for.
• Group interviews. These are similar to the one-on-one interview except that there is more than one person being interviewed. Group interviews require more preparation and more formality to get the information you want from all the participants. You can uncover a richer set of requirements in a shorter period of time if you can keep the group focused.
• Facilitated sessions. In a facilitated session, you bring a larger group together for a common purpose. In this case, you are trying to gather a set of common requirements from the group in a faster manner than if you were to interview each of them separately. 
• JAD sessions. Joint Application Development (JAD) sessions are similar to general facilitated sessions. However, the group typically stays in the session until the session objectives are completed. In this case, the participants would stay in session until a complete set of requirements is documented and agree to. 
• Questionnaires. These are much more informal, and they are good tools to gather requirements from stakeholders in remote locations or those that will have only minor input into the overall requirements. A questionnaire can also be a valuable way to gather quick statistics, such as the number of people who would use certain features, or to get a sense for the relative priority of requirements.
• Prototyping. Prototyping is a relatively modern technique for gathering requirements. In this approach, you gather preliminary requirements that you use to build an initial version of the solution – a prototype. You show this to the client, who then gives you additional requirements. You change the application and cycle around with the client again. This repetitive process continues until the product meets the critical mass of business needs, or for an agreed number of iterations.
• Following people around. This is especially helpful when gathering information on current processes. You may find, for instance, that some people have their work routine down to such a habit that they have a hard time explaining what they do or why. You may need to watch them perform their job before you can understand the entire picture. In some cases, you might also like to participate in the actual work process to get a hands-on feel for how the business function works today.

Knowing the stakeholders that will provide requirements will help you determine the right techniques to utilize to best meet your needs. You should select techniques that get you the most relative information and are best suited for the audience.

Back up Your Estimates with a Full Estimating Packet

A lire sur: Method123

After you have prepared your project estimates for effort, cost and duration, you need to defend it if the sponsor thinks that the numbers are too high. It is important that these estimates be accepted since they form the basis of your schedule and budget. You should be able to defend the estimate by providing an "estimating packet". This includes:

• Your understanding of the work
• The estimating technique(s) you used
• Your estimate of the effort hours, duration and cost
• The detailed estimating information in case the sponsor would like to review
• Your estimating assumptions
• The level of uncertainty as reflected in the estimating range

If the sponsor still thinks the numbers are too high, or cannot afford the solution at that cost, there are a few alternative options.

• Determine if the client has any additional information that would allow you to revise your assumptions and perhaps revise the estimate. For instance, if a critical end-date now has some flexibility, perhaps the estimate can be revised based on this new information.
• Determine whether high-level requirements and functionality can be scaled back. In many cases, the original set of features and functions is more of a wish list. After seeing a price tag, it is very possible that the client can live without certain features.
• If you included a high contingency to reflect a high estimating risk, ask the client for more time to gather more detail for the estimate. This may result in there being less uncertainty and risk, and allow you to reflect this as a smaller contingency.

Understand Your Client's Expressed Needs and Their Real Needs

A lire sur:  Tenstep

The needs of the client are formally addressed in the Business Case. This document describes what the client is trying to achieve, the benefits the client expects to gain, and the costs they expect to pay.

If the Business Case is approved, the project manager works with the client to understand their needs at a more detailed level. This results in a Project Charter. The Charter specifically describes the needs of the client in terms of objectives, deliverables and success criteria. The Charter also describes additional aspects of the project that need to be managed for the project to be successful. This includes project assumptions, risks, constraints, detailed costs, etc.

If the Charter is approved, the detailed needs of the client are gathered in the business requirements. The business requirements describe the features and functions the client desires, the level of quality they expect, and other expectations related to the deliverables of the project. 

One of the primary reasons that projects struggle is that the project team does not fully understand the client's needs. This leads to rework, missed expectations, extensive changes and ultimately delivering late and over budget.  

It is important for the project manager and project team to understand that the true needs of the client may or may not be the same as the needs that are expressed to you in the Charter and the business requirements. In many cases, the client does not understand their true needs when the project starts. The true needs can sometimes evolve over the course of the project. Likewise, the client may have a vision of their needs, but they may have a hard time expressing the needs to the project team.

The project team must focus on the expressed needs of the client and use the expressed needs as the basis for the approval of the Charter and business requirements. However, knowing this idea of expressed needs and real needs, the team must be diligent to ensure that they do as good a job as possible uncovering the true needs of the client.

You can ask the client what they need and the client may tell you. But are they expressing their real needs? Gathering requirements involves more than just asking a few questions and then building the solution. Projects with any degree of complexity requires a formal process to ensure that all of the requirements are accurately gathered, reviewed, documented and approved.

You validate you are hearing the real needs by asking good questions, asking targeted follow-up questions, gathering input from all key stakeholders, asking more questions when requirements don't seem to make sense, etc. If your approach to gathering information from the client is shallow and hurried, you will end up with information that might not reflect what the client really needs. The closer the true needs of the client are to their expressed needs, the closer you will be to getting the project right the first time.

N°180: Structure de découpage du projet

A lire sur: Tenstep

Découpez les activités sommaires en deux activités détaillées ou plus

Puisque vous avez choisi de diviser une activité - sommaire en de plus petites activités, il n’est pas logique d’en inscrire une seule sous une activité - sommaire. Si vous le faites, l'activité détaillée représente exactement le même travail que l'activité récapitulative. Cela ne vous apporte rien. Si cela se produit dans votre SDP, vous aurez le choix entre:

·         diviser l’activité - sommaire en de multiples tâches plus petites

·         ou vous débarrasser de l'activité détaillée et associer le travail à l’activité - sommaire, qui devient alors une activité détaillée.

Les activités détaillées devraient être inscrites en tant qu'activités axées sur l'action

Les activités détaillées de votre SDP sont transférées dans votre échéancier. Pour cette raison, leur transfert est plus facile si elles sont axées sur l'action, exactement comme les activités de votre échéancier devraient l’être. Par exemple, au lieu d'énoncer une activité détaillée de SDP en tant que "meeting", vous devriez l'énoncer en tant que « prévoir une réunion hebdomadaire ». Au lieu d'avoir une activité détaillée pour « le plan d'essai », vous devriez l'énoncer plutôt comme " créer le plan d'essai ". De cette façon, les activités détaillées peuvent être déplacées vers l’échéancier avec un minimum de changements de terminologie.

Ne placez pas les exigences sur la SDP

La SDP est utilisée afin de découper de plus grandes parties de travail en sections plus petites. Si vous placez un livrable sur votre SDP, vous pouvez le découper en activités qui permettent par la suite la création de ce livrable. Le découpage des livrables ne doit pas déboucher sur les exigences qui le décrivent. Les exigences ne font pas partie de la SDP.

Les activités détaillées de votre SDP sont transférées dans votre échéancier. L'échéancier ne contient pas des items tels que : « a besoin d'avoir une interface simple » ou « doit pouvoir travailler 25 pieds sous l'eau ». Ce sont là des constats d’exigences. Les exigences appartiennent au plan de gestion des exigences. Elles n'appartiennent ni à l’échéancier ni à la SDP.

Pour les grands projets, vous pouvez laisser votre SDP au niveau des « lots de travail »

Les très grands projets ont généralement des livrables de très grande taille. Un des moyens permettant d'élaborer votre SDP pour ces projets, consiste à définir vos livrables puis à les diviser en composants plus petits. Quand tous les composants sont accomplis et intégrés, le plus grand livrable sera alors créé.

Parfois, quand il s’agit de projets très grands, il n’est pas pratique de déterminer les activités - sommaires et les activités de détail, tout simplement parce qu’il y en a un très grand nombre. Dans ces grands projets, la SDP peut seulement être décomposée jusqu’au niveau des « lots de travail ». Le lot de travail peut être assez grand pour constituer un sous-projet et quelquefois assez grand pour qu’un compte de coût lui soit rattaché.

Dans un grand projet, vous pouvez arrêter la SDP au niveau du lot de travail. Cependant, le travail ne devrait pas être assigné aux membres de l'équipe à ce niveau. Le lot de travail devrait être attribué à une équipe. Le chef de l'équipe doit encore découper le lot de travail en activités permettant de réaliser le composant de travail (ou de réaliser tout le contenu du lot de travail).

Dans ce scénario, La totalité de la SDP est ramenée vers le niveau inférieur des activités détaillées. Cependant, cette opération se déroule en deux temps : la première itération s'arrête au niveau élevé du lot de travail, alors que les activités détaillées sont définies quand le lot est réellement assigné à une équipe de travail.

Terminologie de management de projet

Plan de management du contenu. Document qui décrit la méthode de définition, de développement et de vérification du contenu, la méthode de création et de définition de la structure de découpage du projet, et qui procure les directives de management et de maîtrise du contenu du projet par l'équipe de management du projet. Il fait partie du plan de management du projet ou y contribue comme plan subsidiaire. Aussi appelé Plan de gestion du contenu dans certains pays francophones.

Produit. Objet qui est produit, quantifiable, et pouvant aussi bien être un produit final qu'un composant. Les termes matériaux et marchandises sont similaires à produits. À comparer avec Résultat. Voir aussi Livrable.

Abréviations courantes

RAM (anglais) : Responsibility Assignment Matrix

         (français) : Matrice d'affectation des responsabilités

Réussir la Gestion de projets critiques : les pièges à éviter et les pistes à suivre

A lire sur:  http://www.infodsi.com/articles/142108/reussir-gestion-projets-critiques-pieges-eviter-pistes-suivre.html

jeudi 11 juillet 2013

Les organisations les plus performantes reconnaissent qu’une gestion efficace des programmes et des projets est fondamentale dans les environnements opérationnels très complexes d'aujourd'hui. Dans le secteur des technologies de l’information, ces environnements se caractérisent par le recours à de nombreux fournisseurs qui offrent à la fois des infrastructures, des applications et des services business. Information Services Group (ISG) examine les enjeux liés à la Gestion de Projets et dévoile les étapes à suivre pour constituer et mettre en place une équipe performante de gestion de programme / projet (PMO) afin d’assurer un suivi efficient des projets opérationnels critiques. Voici son analyse.


Souvent, plusieurs projets concurrents se trouvent dans le pipeline. La nature de ces projets varie : mises à jour des composants de l'infrastructure, des interfaces de systèmes, des fonctionnalités applicatives, ou encore des initiatives business concernant le déploiement de nouveaux produits et des campagnes marketing. Quant aux chefs de projet, ils sont généralement issus de profils différents comprenant fournisseurs, prestataires de services et sous-traitants.


Dans de tels environnements, apparaissent des insuffisances, notamment dans les normes et les règlements qui régissent la Gestion de Projet.

Cela peut entraîner un impact négatif et significatif sur la performance opérationnelle qui peut être mesurée par une baisse de la rentabilité, de la productivité et de la qualité de service. D’autres défis pour les Projects Managers (PM) se manifestent à la fois à un niveau micro-économique, en termes de projets distincts, ainsi qu’à un niveau macro, en termes de multiples projets interdépendants dans le cadre d'une stratégie opérationnelle plus large.



Des enjeux organisationnels

Dans les environnements actuels, plusieurs facteurs contribuent à un manque de structures efficaces de PMO ou de processus de Gestion de Projet. Tout d’abord, il y a la complexité inhérente des organisations ayant une myriade de fournisseurs et infogérants. En outre, même si la plupart des entreprises reconnaissent les avantages de la Gestion de Projets, les budgets sont limités et les priorités sont divergentes… ce qui fait que la Gestion des Projets est souvent reléguée en fin de liste d'attente des initiatives à mettre en œuvre.

Obtenir le soutien de l’ensemble de l’organisation pour la Gestion de Projet présente également un défi. Avant de pouvoir imposer un ensemble standard de processus, d’outils et de reporting au grand nombre de clients, de parties prenantes et de fournisseurs, il faut surmonter l'obstacle redoutable du changement. En effet, respecter rigoureusement des processus et des standards est souvent perçu comme une menace chez les fournisseurs qui sont appréciés pour leurs compétences et leur réactivité. Quant aux utilisateurs métiers, ils rechignent à l’idée de suivre des processus, préférant s'appuyer sur des réseaux informels et des relations personnelles. Trop d’entreprises ont rencontré des difficultés en essayant d’instaurer une discipline stricte autour de la Gestion des Projets. Ceci, faute d’avoir démontré que les nouvelles normes sont un moyen pour améliorer les opérations et répondre aux besoins de l’entreprise.



Les défis de la gestion de projets

Trop souvent, les difficultés de la Gestion de Projets ne résultent pas d'un manque de processus, mais plutôt d'une multitude de normes. Certains chefs de projet appliquent une variété de processus et d'outils de suivi et de reporting, qui génèrent non seulement beaucoup de confusion, mais surtout des résultats incohérents entre les fournisseurs et les parties prenantes de l'entreprise. Puisque chaque fournisseur utilise un processus unique pour produire les rapports sur les livrables du projet, il devient impossible de suivre le projet dans son intégralité, ou d'évaluer ensuite la valeur ajoutée.

Le manque de normalisation et de formations croisées a des conséquences pour les entreprises, dont la difficulté de pallier au remplacement d’un chef de projets absent. De plus, le partage de connaissances devient infructueux sans fonctions de bibliothèque pour déposer les documents relatifs aux projets communs, et sans normes pour le workflow des documents et le contrôle de versions. Les incohérences et la multiplication de normes limitent également la capacité à bien cibler les portefeuilles, ce qui influe sur le suivi et la gestion de l’interdépendance des projets et leur impact sur la performance globale.

Un autre problème structurant réside dans l'absence de mesures basiques pour évaluer l'efficacité, la productivité et la qualité, mais aussi de normes et de processus clairement définis pour les méthodologies de projet, les produits livrables ou la performance du personnel. Des modèles communs ou des plannings concernant des projets ainsi que la gestion des changements sont rarement établis ou suivis. De la même façon, des chartes, des plans de gestion et d’assurance qualité, des analyses de projets et des rapports de transfert des connaissances sont tout aussi rares Des problèmes similaires caractérisent le reporting sur la charge de travail, les ressources, les risques, les questions ou le statut du projet. Enfin, beaucoup de projets manquent de contrôles communs, de mécanismes ou de tableaux de bord de suivi, ou encore de processus intégrés de remontée des incidents.

Si la gestion de projets distincts est souvent caractérisée par un dysfonctionnement, les entreprises s'efforcent également d’améliorer la visibilité de leurs portefeuilles de projets. Plutôt que de prendre une vision d'ensemble qui tient compte de l'interdépendance des multiples projets et gère l'ensemble du programme de services, nombreuses sont les entreprises qui traitent des projets de façon isolée. En conséquence, l'utilisation et la planification des ressources sont réduites, et les flux et reflux de la demande ne peuvent pas être anticipés.

« Les bonnes pratiques de gestion de projet doivent s’inscrire dans un cercle vertueux, explique Julien Escribe, Partner. En particulier, il faut donner le droit à l’erreur (au moins une fois…) à tout Project Manager. Une des philosophies de la NASA est qu’on ne punit jamais quelqu’un pour ses erreurs, mais qu’on punit pour avoir caché une erreur ! L’application de ce principe dans la plupart de nos grandes organisations aurait à coup sûr un effet très bénéfique ».



Qu'est-ce qui caractérise un PMO (Project Management Office) efficace ?


La vision micro

Pour des projets distincts, le PMO établit des processus cohérents afin de définir la charte du projet, les exigences, les équipes commerciales et techniques. Mais aussi les mesures et les normes autour de management de la qualité, de la communication et des réunions. La cohérence entre ces activités est essentielle pour éviter toute confusion entre les fournisseurs et les métiers.

Un rapport de réalisation des bénéfices veille à ce que chaque projet soit évalué en fonction de ses besoins et de la valeur ajoutée pour l'entreprise tel que précisé dans la charte du projet. Ceci encourage l’évaluation permanente des performances et l'alignement sur les stratégies métiers telles que la réduction de la durée d'une campagne de marketing ou l’accélération du cycle de développement de produits. Les processus de contrôle et de gestion de changements comprennent un processus de demande de service intégré à la gouvernance de contrat, permettant ainsi le transfert transparent de demandes de service au sein du flux de travail. La gouvernance du contrat garantit que toutes les activités du projet appartenant aux fournisseurs sont à la fois intégrées et adaptées au périmètre et au bon prix dans le contexte du contrat global.


La vision macro

La partie de Gestion de Programme du PMO gère les initiatives métiers spécifiques qui impliquent plusieurs projets connexes, y compris les projets dirigés par des fournisseurs, afin de coordonner et intégrer les activités tout en s'assurant que les objectifs métiers sont réalisés. Des fonctions spécifiques au PMO comprennent la création de tableaux de bord pour le suivi et le reporting de plusieurs projets, avec les étapes clés bien définies. Des règles de priorité pour les parties prenantes et les clients sont établies et appliquées à chaque projet, tout comme les mesures autour de la complexité, l'effort, le risque et l'interdépendance du projet. Ces vues agrégées de la charge de travail, des ressources, des risques, des enjeux et de l'état permettent de suivre et réaliser des reportings sur les performances de l'ensemble du portefeuille.


La gestion au quotidien

Un PMO peut être géré par une équipe client ou fournisseur de service, ou par un tiers indépendant. Cette dernière approche présente beaucoup d’avantages, puisqu’une perspective objective et impartiale sur les programmes et les priorités souvent contradictoires est essentielle à un PMO efficace. En tant que tel, un PMO géré par une tierce partie est généralement plus susceptible de donner un aperçu transparent et de représenter équitablement les intérêts de multiples fournisseurs.


Les avantages

Un PMO efficace débarrasse l’organisation fonctionnelle du client du fardeau de la gestion de projet. Plutôt que de gérer des projets de manière isolée et des portefeuilles globaux, l'organisation fonctionnelle détermine quels projets sont dans le périmètre à gérer et définit les priorités métiers. Ensuite, le PMO accorde la compétence de base et l'expérience d'un chef de projet avec les besoins métiers afin de s'assurer que les livrables du projet et des métiers reçoivent le bon niveau d'expertise et de compréhension.


Les clés de la réussite

« La gestion de programmes s’apparente à un exercice de jonglerie. Il faut toujours avoir 3 balles en l’air : les délais, les coûts, la qualité. Pour se représenter une entité de PMO performante, il suffit d’imaginer une équipe professionnelle de plusieurs jongleurs qui s’assurent que toutes les balles restent constamment en l’air », déclare Julien Escribe.

La gestion de projets efficace exige un équilibre délicat entre le besoin d’appréhender la situation dans son ensemble, tout en se concentrant sur les détails à un niveau plus granulaire. Plus précisément, les entreprises ont besoin d'équilibrer la demande et les priorités des métiers avec les ressources disponibles sur l'ensemble du portefeuille, tout en veillant à ce que chaque projet soit géré efficacement.

La communication entre l'organisation fonctionnelle et le PMO est essentielle pour relever ce défi. À un niveau supérieur, le PMO doit suivre les besoins en ressources pour les projets en cours et à venir pour s'assurer que les initiatives critiques soient correctement staffées et que les ressources ne soient pas absorbées par les projets de faible priorité.

Le soutien des cadres dirigeants est un autre élément essentiel pour le succès du projet. Comme pour tout changement organisationnel, la résistance peut être difficile à surmonter sans leadership et soutien de la hiérarchie. L’un des moyens les plus efficaces pour les exécutifs est le soutien apporté au travers d’une participation dans les revues et les décisions liées à la Gestion des Programmes.


Distinguer « important » et « urgent »

Les entreprises se rendent compte que, dans les environnements multi-fournisseurs très complexes, les questions liées à une mauvaise gestion de projets ne sont pas seulement importantes, mais également de plus en plus urgentes, car elles ont un impact majeur sur la performance opérationnelle et, à terme, sur l’atteinte de la stratégie de l'entreprise.

ISG a observé que les entreprises les plus performantes relèvent le défi et prennent des mesures pour mettre en œuvre des initiatives de PMO efficaces qui assurent à la fois la gestion des différents portefeuilles de projets, et en même temps appliquent la rigueur et la discipline nécessaire à chaque projet.

Source: infoDSI.com

ANATOMIE D’UN EMAIL n°8: La désinscription

A lire sur: ContactLab

La désinscription est une étape naturelle dans le parcours
du consommateur
On ne peut pas intéresser tout le monde tout le temps et il vaut mieux un
internaute qui se désinscrit qu’un contact qui vous signale comme
spam ou bien qui vous ignore.
Un consommateur désinscrit n’est pas forcément perdu à tout jamais,
il a d’autres moyens de garder le contact avec vous s’il le souhaite.
A vous de le guider dans ce sens et à bien communiquer dans cette étape potentiellement délicate.

Tout d’abord respectez le choix de l’internaute et facilitez la désinscription avec des liens visibles en haut et en bas de votre email avec un processus simple et rapide, sans redemander l’adresse email ou un mot de passe Offrez des alternatives aux internautes changer d’adresse de réception réduire la fréquence ne recevoir de messages que pour quelques rubriques d’intérêt sélectionnées par le consommateur vous suivre sur les autres touch points : réseaux sociaux, blog, site principal Essayez de comprendre les motivations des désinscrits avec un sondage rapide. Une question fermée et une ouverte suffisent pour comprendre : s’agit-il d’un problème de fréquence ? de contenu ? ou tout simplement d’un changement de situation chez le consommateur qui rend vos messages moins pertinents ? Ces réponses vous vous aideront à optimiser vos campagnes futures.

Révolution numérique, il faut changer la culture de l'entreprise

A lire sur:  http://www.usine-digitale.fr/article/revolution-numerique-il-faut-changer-la-culture-de-l-entreprise.N201178

Publié le mardi 9 juillet 2013

Révolution numérique, il faut changer la culture de l'entreprise © DR

Le digital s'insère partout mais, pour l'instant, seuls 2 % des entreprises française ont passé la transition numérique. Le chemin va donc être difficile...

Il faut partir d'un constat, le numérique n'est pas un problème de technologie mais de culture pour l'entreprise. En réalité, si les nouvelles technologies s'imposent assez naturellement dans l'entreprise, pour être pleinement intégrées à sa stratégie, elles imposent de revenir sur ses fondamentaux et sur ce qui fait sa valeur.
C'est là que les difficultés s'agglomèrent. Les entreprises vont devoir s'habituer à remettre en cause ce qu'elles savent faire le mieux, pour faire autre chose, encore mieux. Dans cette perspective, beaucoup de fonctions vont devoir évoluer, et dans ces transformations, les Ressources Humaines ont vocation à devenir les principaux acteurs du changement.
L’école n’est plus le sanctuaire de la transmission de la connaissance, Google est plus efficace et plus rapide

Qu'est ce qui est en train de se passer ? On est un peu comme en 1895 lors de l'arrivée des véhicules à moteur dans Paris : les premières voitures ont bousculé la ville et ses habitudes… et 25 ans plus tard les chevaux avaient disparu de la capitale. Des métiers ont disparu, d'autres sont apparus.
Aujourd'hui c'est le même phénomène, il suffit de prendre l'exemple de Kodak, il y a 25 ans c'était la référence de la photographie et du traitement de l'image. Pourtant, avec le développement du numérique, ce secteur s'est profondément transformé, et Kodak s'est effondré, l'entreprise est passée de 180 000 salariés à moins de 10 000. Pourtant la photographie n'a pas disparu, on prend même plus de photos qu'avant, mais on est passé de l'ère de l'argentique et du marketing à autre chose… le numérique !
Dans le domaine de l'enseignement, c'est le même phénomène, les institutions ne sont pas pensées pour le numérique, ce qui explique qu'on bricole plus qu'on ne transforme. L’école n’est plus le sanctuaire de la transmission de la connaissance, car Google est plus efficace et plus rapide. Si l'éducation numérique n'est pas un cours filmé, nos institutions peinent à trouver une formule. Il n'y a qu'une seule question à se poser pour trouver le salut : qu’est-ce qu’enseigner aujourd’hui ?

Comment faire pour ne pas subir la transformation numérique du monde ? Il faut repenser tous ses fondamentaux et tout ce qu'on ce prenait pour vrai ! Kodak avait tous les chercheurs (et les brevets) pour faire évoluer son business mais l'entreprise n'a pas pu envisager la disparition de son coeur de métier, le développement de photo, c'est pourquoi elle a à son tour disparue.
Demain, Google commercialisera des voitures
Si les salariés "de base" ont souvent déjà pris conscience des évolutions de leur métier, les managers et les dirigeants doivent oser s’affranchir des référentiels connus pour aller dans l’inconnu. Nous ne pourrons le faire que si tout le monde bouge : dirigeants, managers, salariés, fournisseurs, institutions... tous doivent aujourd'hui travailler de concert, main dans la main.
A l'instar d'Amazon, qui a révolutionné le commerce en ligne, les entreprises ne doivent jamais considérer un marché comme acquis. L'entreprise continue de se réinventer une histoire et remet constamment en cause ses métiers, ses recherches... Nul ne sait par exemple ce que le géant américain proposera dans les prochains mois.
Voilà un challenge pour les entreprises françaises qui voudront encore compter demain. Hier, PSA Peugeot Citroën était l'un des indices phares du CAC 40, aujourd'hui il n'en fait plus partie. Demain, Google commercialisera des voitures, on peut décidément s'attendre à tout.
Nous ne sommes qu'au début de la remise à plat de notre système de pensée, en attendant interrogeons nous sur la raison d'être de nos entreprises.
Yann-Maël Larher, doctorant en droit social à Assas sur les TIC dans l'entreprise

Six Steps for Scope Changes on Small Projects

A lire sur: Method 123

Since small projects are much easier to define and completed quickly, they typically do not have many scope change requests. If scope changes occur, they are typically also small in nature. Even though the changes are small they still need to be documented and managed.

The following simple process should be used able to be performed quickly.

1. Identify scope change request
   
   Scope changes can be surfaced by anyone on the project team. They should be sent in writing to the project manager by paper, email, etc. No formal form is needed.
2. Enter change in Scope Change Log
   
   Even small projects need to track changes. 
    
3. Determine the impact of the request
   
   The project manager determines the impact of the scope change to the project in terms of cost, effort and duration. If there are multiple viable options, the project manager determines their impact as well.
    
4. Determine the value of the change
   
   The person that requests the change should also validate the benefits of the change. For a small project this may not be a qualitative value, but might be expressed in subjective terms.
    
5. Take the information to the appropriate approver
   
   The appropriate analysis, impact and alternatives are taken to the project sponsor (or other designated person) for resolution. If the sponsor does not approve the request and the corresponding impact, the scope request is not pursued.
    
6. Update Scope Change Log
   
   Update the Scope Change Log with the sponsor decision - accept or decline.

This simple process will ensure you maintain control of scope and reduce scope creep. 

Seven Elements of a Quality Management Plan

A lire sur: Tenstep

 

The Quality Management Plan describes how you will ensure that the client’s quality requirements are achieved. It is the place to describe the processes and activities that will be put into place to ensure that quality deliverables are produced. The Quality Management Plan also helps you understand when deliverables are complete as well as correct.

The actual quality requirements are not known at the time the Quality Management Plan is created, but you should describe the processes and techniques that you will use to uncover the quality requirements and verify that the requirements are met. The information in the Quality Management Plan includes:

• Roles and responsibilities. Describe the different quality related roles on the project. The project manager has overall responsibility, but you may have other roles that are assisting. These could include quality auditors, third-party testing specialists, inspectors, etc.
• Completeness and correctness criteria. The purpose of the completeness and correctness criteria is to work with the customer up front to define what it means for a deliverable to be considered complete and correct. Then, when you meet those terms, you would expect that the customer would be satisfied. In other words, there should be no surprises.
• Quality requirements process. Describe the process you will use to uncover and validate the customer’s expectations for quality. This is generally going to be a part of the requirements gathering process.
• Quality assurance activities. Quality assurance activities focus on the processes being used to build the solution, and can be validated by a functional manager, business sponsor, or a third-party reviewer. You should describe the major quality assurance activities and techniques that will be used on this project.
• Quality control activities. Quality control activities are performed continually throughout a project to verify that project deliverables are of high quality. You should describe the major quality control activities and techniques that will be used on this project.
• Quality standards. List any quality standards that the company or organization has previously defined that this project will follow.
• Quality tools. List any quality-related tools that this project will utilize.

The Quality Management Plan is where you think ahead of time about how you will understand the customers expectation for quality, and how you will deliver to that expectation. Once the project starts this Plan provides guidance on how you will manage quality throughout the project.

Élaborer l'échéancier et le budget du projet

A lire sur:  tenstep

L'échéancier du projet doit être élaboré parallèlement à la charte du projet réalisée au cours du processus 1.0 Définir le travail. L'échéancier du projet est un outil vital pour s’assurer que l’équipe de projet sache ce qu’elle doit accomplir.

Le budget représente les sommes d’argent disponibles pour les dépenses encourues dans le cadre du projet. En fonction de votre organisation et de la manière de tenir votre comptabilité, le budget pourra couvrir uniquement les coûts externes du projet (fournisseurs, hardware, logiciels, matériel, etc.). Certaines organisations incluent également le coût du travail interne dans le budget. Ces organisations disposent en général de certains processus d’imputation des coûts, permettant d’assigner les coûts internes aux clients de l’organisation ou à leur propre service à la clien

Au cours du processus 1.0 Définir le travail, vous avez obtenu l’accord du commanditaire sur le travail qui doit être réalisé. À présent, c’est le chef de projet qui détermine comment le travail sera effectué. Suivant la taille du projet, il est possible d’utiliser un pack de gestion de projet comme MS Project, une feuille de calcul de tableur, ou tout simplement garder mentalement une trace des activités.

La relation entre l’échéancier et le budget

La méthodologie TenStep a toujours jumelé l'échéancier et le budget en un seul processus intégré. Cependant, bien que liés, ces deux concepts sont différents. L’échéancier du projet indique les activités nécessaires pour concevoir les livrables du projet. Le budget indique les sommes d'argent nécessaires à la réalisation du projet ainsi que le calendrier des dépenses.

Le processus TenStep considère qu’il s’agit de deux processus fondamentaux essentiels à la réussite du projet. Dans de nombreuses organisations, ils représentent les deux éléments fondamentaux pour mesurer la réussite du projet : a-t-on rempli les attentes par rapport à l’échéancier et au budget? Il est évident que ces deux éléments de la gestion de projet sont généralement liés.

·         Si un projet est en retard, il dépasse fréquemment son budget.

·         Si un projet dépasse le budget, il a généralement tendance à excéder les délais. (Évidemment, il y a des exceptions, mais les deux éléments ont généralement une tendance commune.)

·         Si vous avez sous-estimé la charge de travail nécessaire, c’est-à-dire l’effort, vous êtes dans une situation d’avoir sous-estimé autant la durée que les coûts.

·         Les heures d’effort véritablement nécessaires auront un impact autant sur l’échéancier que sur les coûts.

·         Ces deux éléments font partie de la triple contrainte globale du projet qui relie les délais, les coûts et le contenu du projet. Si le contenu du projet est augmenté (ou diminué), les délais et/ou les coûts seront affectés.

L'expérience révèle qu’un rapport étroit existe entre les délais et les coûts du projet.

Relation entre définir et planifier le travail

Il est à noter que « définir le travail » représente le processus 1 de la Méthodologie TenStep, et que créer l'échéancier et le budget représente le processus 2. Cependant, cela n’implique pas que ces étapes se déroulent consécutivement. Vous vous rendrez compte que vous ne pouvez pas compléter votre définition de projet sans d’abord concevoir son échéancier. Dans de nombreux cas, ces deux livrables doivent être élaborés en parallèle. Au fur et à mesure que vous rassemblerez des renseignements sur le contenu et les livrables du projet, vous éprouverez le besoin de commencer à concevoir une courbe chronologique et, sur cette base, vous procéderez à l’estimation de l'effort de travail et de sa durée. À travers les renseignements utiles recueillis pour la « définition », vous pourrez compléter plus en détail l'échéancier du projet. Lorsque les livrables, le contenu, les hypothèses et l’approche seront définis, vous devriez avoir suffisamment de renseignements dans l'échéancier du projet pour estimer le budget nécessaire, l'effort de travail et la durée – éléments qui seront à leur tour utilisés pour compléter la charte du projet.

Terminologie de management de projet

Plan de management des risques. Document décrivant la future structure du management des risques du projet et la manière dont elle s'appliquera au projet. Ce plan est inclus dans le plan de management du projet ou peut y figurer comme plan subsidiaire. Les informations contenues dans le plan de management des risques varient selon le champ d’application et la taille du projet. Le plan de management des risques diffère du registre des risques qui contient la liste des risques du projet, les résultats de l'analyse des risques et les réponses aux risques. Aussi appelé Plan de gestion des risques dans certains pays francophones.

Processus de clôture. Processus effectués pour finaliser toutes les activités dans tous les groupes de processus de management du projet pour clore formellement le projet ou l'une de ses phases.

Abréviations courantes

LS (anglais) : Late Start date

     (français) : Date de début au plus tard