My wife's first WBS

I'm so proud! My wife has a lot of things to do between preparing for Thanksgiving and the big church retreat. She was explaining them all to me so I told her she needed to create a Work Breakdown Structure. I started her off, showing the difference between projects, deliverables and activities. Then I headed outside to do some work. By the time I returned, here is what I found:

She did everything right and is using it to complete all her work. Deliverables are all nouns, activities are verb-noun format.

 

Good job Kathy!

Dear PM Advisor. Oct. 20, 2014

Dear PM Advisor,

What’s a WBS Dictionary and how do you use it?

Poor Speller in Chicago

Dear Poor Speller,

The Work Breakdown Structure (WBS) is the oldest tool in the Project Manager’s toolkit and one of the more graphic ones. It is the first opportunity for the PM to express his style as he shows the way he intends to organize the project. Will he organize it by phase, function, or deliverable? How many levels will he go before work starts to be done? I always love watching the way a PM drafts his WBS; it is a look into his mind.

One thing about a graphic tool such as a WBS: there is no room for paragraphs or even sentences. Nouns and adjectives are all you have room to work with. And sometimes a chunk of work requires more than that to allow those executing the work to know what needs to be done. That’s where the WBS Dictionary comes in. It is a tool that provides more detail around a piece of work that is in the WBS. Not every WBS element must be defined, just those that need it.

I don’t strictly use a WBS Dictionary as a stand-alone tool. But when I enter WBS elements into the Gantt chart, I’ll use the Notes tab on that line to enter additional details.

Good luck,

PM Advisor

Send your questions to Bruce@RoundTablePM.com

Dear PM Advisor. Mar 17, 2014

Dear PM Advisor,

Can I make a horizontal Work Breakdown Structure? 

Outside the box in Boston

Dear outside the box,

I suppose you could but I'm not sure of the advantage. And I can think of plenty of disadvantages.

Considering that you have between 3 and 15 activities per deliverable and most projects have more than 15 deliverables, you end up with a rectangular structure with the number of deliverables defining the large side. Creating a WBS on the wall makes it convenient to place the deliverables along the top and your activities below each one. You'll typically have room for the 15 activities though you're stooping near the end.

If you are placing your deliverables vertically, people are working above and below each other rather than next to each other and someone is stooping to fill out the activities on the lower deliverables. Walls are typically wider than taller and it's easier to move sideways than up and down.

Good luck,

PM Advisor

Send your questions to Bruce@RoundTablePM.com

Dear PM Advisor. Mar 3, 2014

Dear PM Advisor,

When I'm generating a Work Breakdown Structure, the pattern for the completion of documents is always the same. Draft, Review, Edit, Review, Edit, Approve. Can't I just list all the documents as the one deliverable, place all the activities underneath it and I'm done with that section of the WBS? It seems a lot easier but I'm afraid I'll pay for it later?

Short-cut in Cambridge.

Dear Short-cut,

As the CarTalk denizens of your fair city are quick to point out: "It's the stingy man who pays the most!" As you suspect, there will be a payment for taking this short-cut. But it may not be as bad as you suspect.

Just remember what your next steps are after filling out the WBS. The activities need to be placed on the Responsibility Matrix and people need to volunteer for who will take responsibility for them. If they are all the same people on every document, you could be in luck. Most likely this is not the case.

Then the activities need to be placed in the schedule. If you're using MS-Project at this point, a simple cut and paste will help but you'll need to add the word describing each actual document. I'm a big proponent of activities standing alone. You shouldn't have activities named: Review. You'll have to scroll up each time to see exactly what the person is reviewing.

Next you have to add the durations and predecessors and they will vary by document.

My preference is to have each activity broken out within the WBS. You can use this as an opportunity to involve the people who have little to add to the WBS by asking them to repeat the activities you wrote under one document for all the other documents. Great opportunity for some team building.

Good luck,

PM Advisor

Send your questions to Bruce@RoundTablePM.com

Dear PM Advisor, Feb 3, 2014

Dear PM Advisor,

What’s a WBS Dictionary and how do you use it?

Poor Speller in Chicago

Dear Poor Speller,

The Work Breakdown Structure (WBS) is the oldest tool in the Project Manager’s toolkit and one of the more graphic ones. It is the first opportunity for the PM to express his style as he shows the way he intends to organize the project. Will he organize it by phase, function, or deliverable? How many levels will he go before work starts to be done? I always love watching the way a PM drafts his WBS; it is a look into his mind.

One thing about a graphic tool such as a WBS: there is no room for paragraphs or even sentences. Nouns and adjectives are all you have room to work with. And sometimes a chunk of work requires more than that to allow those executing the work to know what needs to be done. That’s where the WBS Dictionary comes in. It is a tool that provides more detail around a piece of work that is in the WBS. Not every WBS element must be defined, just those that need it.

I don’t strictly use a WBS Dictionary as a stand-alone tool. But when I enter WBS elements into the Gantt chart, I’ll use the Notes tab on that line to enter additional details.

Good luck,

PM Advisor

Send your questions to Bruce@RoundTablePM.com

Dear PM Advisor. Nov 25, 2013

Dear PM Adisor,

During last week's post you showed some rules of thumb for breaking down a deliverable into the activities that comprise it. Got any more? I often get told I'm breaking it down too far.

Anal in Austin, TX

Dear Anal,

I have some rules of thumb but remember they are here for the breaking. Use them when you are unsure of how far to break down your work but don't feel constrained by any of them so that you rely solely on the 'rule.'

• 3 - 15 activities per deliverable - If you have less than 3, you either didn't break down the deliverable enough or these are activities that belong under a different deliverable. If you have more than 15, you are either breaking the deliverable down too far or you have more than one deliverable here.
• The 'If it's easier to manage' rule - If a deliverable changes hands often, break it down so that different people will own different activities within it. For example, one person may be responsible for drafting a document or writing code but another person may be responsible for reviewing or testing it. Break that down into two separate activities.
• The '8/80 hour' rule- If an activity takes more than 80 hours of effort, it's not broken down enough. If an activity takes less than 8 hours of effort, it's broken down too far. (Careful with this last one. Reviewing a doc the second time may take only an hour of time but it is a separate activity from the modification activity above it so the 'If it's easier to manage' rule takes precedence.) 

Good luck,

PM Advisor

Send your questions to Bruce@RoundTablePM.com

Dear PM Advisor. Nov 18, 2013

Dear PM Advisor,

I've been working with the same team members on the last three similar projects and they gave me some disturbing feedback lately. They say that the level of detail I get down to in the Work Breakdown Structure is too much. They say it made sense a few years ago but they know how to do the work and don't need to be micro-managed. 

I told them that this was the process and we were successful before so we should stick with it. 

Any advice?

Pedantic in Atlanta

Dear Pedantic,

I love that you stick to a methodology that works but project management requires flexibility. If you have a deliverable that is fairly straightforward and highly experienced team members, you don't need to manage that deliverable as tightly as those more complex deliverables, especially if your team members are less experienced.

Remember that you don't have enough time to manage every activity. The Pareto principle states that 20% of the activities will cause 80% of the delays. Use the below rule of thumb to focus on those activities that are most likely to cause delays.

Here's a rule of thumb for breaking down deliverables into activities when you conduct your Work Breakdown Structure session:

Complex Deliverable/Low experienced team members: 11 - 15 activities
Medium Deliverable/Medium experienced team members: 6 - 10 activities
Simple Deliverable/Highly experienced team members: 3 - 5 activities

Good luck,

PM Advisor

Send your questions to Bruce@RoundTablePM.com

Dear PM Advisor. August 12, 2013

Dear PM Advisor,

I like your idea of displaying project exclusions. But what is your mechanism for surfacing and displaying them? 

Out in Somerset, NJ

Dear Out,

Exclusions are things that could be considered part of the scope of a project but, for reasons of other constraints, we are not choosing to do. In order to prevent false expectations, we need to highlight the fact that these things are excluded from the project's scope.

Often these exclusions are surfaced during the early stages of a project, before planning, and end up in the documents used to authorize a project. But it is during the Planning Phase that we must highlight them. The last thing we want is for powerful stakeholders to believe their pet part of the project is within scope until it is too late and them be disappointed at your' deception.' Make sure they know from day one of the Project Implementation that what they are looking for is not in the project. Then they will push for a Phase II of this product.

But what is the mechanisim? During the Work Breakdown Structure session, as a team, we determine the deliverables of the project. When people bring up items that we agree are not part of the scope of the project, we list them on the flipchart entitled: Exclusions. Continue adding to this throughout the planning session as more false expectations surface.

When you publish your project plan, have a section entitled: Exclusions, and list all these items. But don't lust bulletize scope items under this title or some people will read them and assume they are within scope since they are listed in the Project Plan. Instead, list them in sentence form with the words NOT or ONLY somewhere in the sentence. As in: 'Does not include 14 inch diameter products." or: "Only green and yellow colors are included."

Good luck,

PM Advisor

Send your questions to Bruce@RoundTablePM.com

Dear PM Advisor. June 17, 2013

Dear PM Advisor,

I look at the way you plan projects and you have a lot of repeating activities. For every document you create you ask that the WBS read: Draft, review, edit, review edit, approve. Are you serious? 

Skeptical in Delaware

Dear Skeptical,

When you plan to drive anywhere, do you assume you'll be able to drive the speed limit the whole way, even on on-ramps and turning corners? Do you plan on leaving your driveway at full speed and hitting only green lights? If so, go ahead and plan on creating documents and having them approved immediately. The rest of us who live in a place called 'The Real World' will continue to plan our projects based on reality.

The number of rounds of review you typically require to get a document to the point of being approved is what you should place in your Work Breakdown Structure. Each of these activities must be planned for, someone must take responsibility for them and they must appear in the schedule. If not, you are left with two options, both of them bad:

1. Plan on every document being approved immediately after drafting
2. Write more general activities like: 'Complete document A'

The first option guarantees you will be delayed on your project as each activity comes in late.

The second option leaves you with fingers pointing between the drafter and reviewer of the document as to who is responsible for its delay. 

Good luck,

PM Advisor

Send your questions to bfieggen@gmail.com

Dear PM Advisor. June 3, 2013

Dear PM Advisor,

How do I show parallel activities under one Deliverable in my Work Breakdown Structure? And what about dependent variables where some work only happens if A occurs and other work happens if B occurs? 

Divided in Delaware.

Dear Divided,

A lot of people, when first building a WBS and placing Post-its on a wall representing work, are tempted to turn it into a flow chart, simply because they've done this before. That is NOT what a Work Breakdown Structure is. The WBS is a breakdown of WORK required to complete the project. There is no element of TIME in the structure.

That being said, most people, when building a WBS, will think chronologically. What is the first activity needed to complete this deliverable? What is the second? And so on down the line. When two activities occur in parallel, they want to draw them in parallel. Please don't do that.

For one thing, the structure of WBS won't support that. Deliverables are placed next to each other and the activities line up underneath them. If you try to split them, you'll have to move the Deliverables around. But it's not needed here. When you build your schedule, then the time comes to indicate the timing of the activities. So load up the activities under each deliverable in roughly chronological order and parallel activities line up in a column. It's up to you if you want to put one set of activities under the other set or dovetail them. Either way, the schedule will sort it out.

Now, your second question deals with optional pathways, If-Then statements. Don't build these into your WBS. If you did, how would you show that in your schedule? There are more complex ways of showing loops like GERT but I don't recommend them for normal projects. Leave this technique to organizations like NASA.

Instead indicate the most likely scenario in your WBS and document the assumption and risk associated with this option. People reviewing your project plan may challenge your assumption and ask you to plan for the other option. That's OK. Remember, people approving your Project Plan are not just approving your cost and schedule, they are also approving the assumptions you are using to reach these major constraints.

Good luck,

PM Advisor

Send your questions to bfieggen@gmail.com

Dear PM Advisor. February 4th, 2013

Dear PM Advisor,

What is a 'Work Package?' Different people within my organization call it different things. Is it a part of an activity or a big collection of activities within the Work Breakdown Structure?

Two Minds in Brooklyn, New York.

Dear Two Minds,

The Project Management Institute has made a change in the last few years on its definition of a Work Package. The levels of a Work Breakdown Structure (WBS) used to be titled this from top to bottom:

Level 1: Project Name
Level 2: Tracks
Level 3: Deliverables
Level 4: Tasks
Level 5: Sub-tasks
Level 6: Work Packages

Now that they want you to conduct the Work Breakdown Structure and then define activities as a second step, here are the new levels:


Level 1: Project Name
Level 2: Tracks
Level 3: Deliverables
Level 4: Work Packages

Then you break down the Work Packages during Activity Definition into Activities. PMI doesn't want these activities showing up on the WBS so they define the Work Package as the lowest level on the WBS.

I'm not sure why they did this. But that's the way the PMI now wants it so, if you want to pass your PMP test, you need to know this terminology.

I still do my WBS the old fashioned way as shown above and do it in one shot unless the project is huge and needs to be broken down by different groups. Here's the method I use.

Good luck,

PM Advisor.

Send your questions to bfieggen@gmail.com

Dear PM Advisor October 1, 2012

Dear PM Advisor,

You've mentioned in the past that, when constructing a WBS, 'Flatter is Better.' What do you do when you have a huge project that involves multiple phases like: Research, Pre-Clinical, Clinical Studies, etc.?

Pyramidic in Corning, NY.

Dear Pyramidic,

There are two kinds of pyramids in the world. Most people automatically think of the Egyptian style and build their Work Breakdown Structures in this way. Their work is spread through out the levels of the WBS and it becomes difficult to keep track. Work is easily forgotten. Work that doesn't end up on the WBS is not considered part of the project. So, during the execution phase, when you get around to remembering it, you already have your project's cost and schedule carved in stone and you are in trouble.

If you've been to Central America, you may have seen squared-off pyramids. They have a flat top. Use this style for your WBS. Start by thinking of all your deliverables in any order that makes sense to you. Place them at level two of the pyramid, right below the project name. The activities go right below this second level. This allows for much more visibility and deliverables are less likely to be forgotten.

It's all about ensuring that, during the planning, you capture all the work needed to complete your project. Using this style, it is easier to ensure you have done so.

You bring up the point of very large projects where the list of deliverables may become unwieldy. For these projects I recommend using Workstreams: groupings of deliverables that make sense. For these projects, move the deliverables down to level three of the WBS and title level two with your phases: R&D, Preclinical, Verification, Clinical, Regulatory Filings, etc. Other large projects may find different titles for workstreams that group the deliverables in a more logical way. When done, your team can look at each workstream and verify that the correct deliverables are in each before determining the activities that make up each deliverable.

Good luck,

PM Advisor

Send me your questions at bfieggen@gmail.com

Free WBS Software

A friend told me about a free web-based Work Breakdown Structure tool so I gave it a shot. It's pretty good. Looks nice when printed out and exports well to MS-Project for scheduling. Check out their Web site.

Here's what it looks like when it's exported to Project:

Dear PM Advisor July 30, 2012

Dear PM Advisor,

I'm learning to plan projects and am using a Work Breakdown Structure for the first time. My project is an R&D project that requires us to run many raw materials through the process steps of a steel mill. Can I make ingots of steel one of the deliverables in the WBS?

Peru Steeler

Dear Peru Steeler,

The Work Breakdown Structure (WBS) is a deliverables-based decomposition of project work. Deliverables are of two types:

1. Operating Deliverables are the tangible items you have remaining when the project is over. These enter the ongoining operations environment when the project is over and you can touch them. (New equipment, processes, software, etc.)
2. Project Deliverables are tangible elements of the project that are required during the project duration that won't enter the operating environment (Beta-test versions of software for example)

These deliverables are placed at level two of the WBS and are broken down further into activities.

Where do raw materials fit in the WBS? They may appear in the activities but never in the deliverables. Just like any other project that requires tests to be run, the product being run through the tests is never part of the WBS. Your deliverables may be items like: New Machinery, New Processes, New Procedures, Trained Operators. When you break down these deliverables you may end up with activities like: Develop new procedures, run ingots through machinery, analyze results, gather more materials, process ingots into bars, etc.

So the ingots and any other raw materials may be used in the project and appear as activities in the WBS but they do not belong in level 2 of the WBS: The deliverables.

Good luck,

PM Advisor

Send your questions to bfieggen@gmail.com

How to plan a project

Here's an article I wrote a few years back showing how to plan a computer systems validation project. The methodology works for any project and it's the way I've been successfully planning projects for twenty years.

Project management techniques are universal. The proven, time-honored disciplines that make up project management can be effectively utilized and applied by virtually any manager, leader, or team member—regardless of industry, profession, or job title. The same skills I have used to develop and bring medical devices to market I have used to remodel my home and, most recently, validate pharmaceutical systems.

As Vice President of Project Management at QPharma, I train my project managers in a system I have developed over the years called Progressix^SM. The word is derived from three concepts central to my teaching:

1. Progressive elaboration. The concept that a project needs to be elaborated progressively as we move from Idea^*, to Purpose^*, to Objective^*, to Work Breakdown Structure*, to Responsibility Matrix^*, to Schedule^*, to Budget^*, to Risk Analysis^* to full Project Plan^*. The project continues to be elaborated through execution and into closeout. (I first learned this order of project elaboration 9 years ago through a class I took from Cadence Management Corporation and have used it successfully since.)
2. Six honest serving men. I use a poem from Rudyard Kipling to illustrate the key things that need to be known about a project to ensure a good, manageable plan.

I keep six honest serving men

(They taught me all I knew)

Their names are WHAT and WHY and WHEN

And HOW and WHERE and WHO

3. Progress. Using the Tuckman Model, progress is made when the team moves from an awareness phase (which Tuckman refers to as FORMING*) through a conflict / control phase (STORMING*), a cooperation phase (NORMING*), and, finally, a productivity phase (PERFORMING*). This concept is evident with any group and is particularly useful in project teams.

So how do I go about this progressive elaboration? Let me use the example of a computer system validation we recently planned for a client. I became involved in a project that was already underway, because it was in trouble and the client had seen the success I had at projects in other departments.

The project was a corrective action tracking system. I was present at a very contentious meeting where two sides, the Clinical and the Information Services departments, were pointing fingers about how the project should progress. The meeting was very acrimonious, with little likelihood of any work being accomplished in the future.

Someone suggested I intervene, so I asked a simple question: “Who is the project manager?” Two hands rose, and I nodded, expecting them to glare at one another. But they had a different problem. One said she was the project manager from the programming group, and the other claimed to be the project manager from the users’ group. They added that they loved working together. I announced, however, that there can be only one project manager, and they needed to decide who it would be. The programmer was decided upon.

I requested that all the project participants, including the users and heads of the clinical and IS^* departments, be present the following week at an all-day project kick-off session, which I would facilitate. They all agreed and, when the meeting time was decided, I sent out an agenda as shown below:

AGENDA

Time	Item	Led by..
9:00 – 9:05	Check in at room, Introductions	Bruce
9:05 – 9:15	Icebreaker exercise	Bruce
9:15 – 9:30	Project Background	IS & clinical heads
9:30 – 10:00	Project Objective	Bruce
10:00 – 10:30	List of Deliverables	Bruce
10:30 – 10:45	Break
10:45 – 12:00	Work Breakdown Structure	Bruce
12:00 – 1:00	Working Lunch
12:00 – 2:00	Responsibility Matrix	Bruce
2:00 – 2:15	Break
2:15– 4:30	Schedule	Bruce

I arrived early, and posted my responsibility matrix and schedule charts on all the walls. People were slow to arrive (is this an IT thing or is it just me?), but they were all present just before 9:30. I scanned the room and, sure enough, Clinical was on one side, IT on the other.

I started with introductions and then we went into a quick icebreaker exercise, which melted rather than broke the ice in that room. The one I chose was participant bingo, where I had a 5 x 5 matrix filled out with things like: “Drives a red car; Has more than three children; Loves the show Survivor,” etc. People tried to achieve Bingo by taking it around and getting people to sign their names in the appropriate box.

Next, I entered the six serving men scenario by answering the first question: WHY? Both department heads were able to speak their piece. Why are we doing this project? Why is it important to the company? Why is it important to the various departments and participants?

During this project background session, the location of the project, WHERE, was easily answered as only the US offices, nowhere else in the worldwide offices of this company

Then I took over. The room was clearly in a FORMING mode,