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.