Your WBS Coach
Published by Josh Nanhivel at Smashwords
Copyright © 2010 Josh Nankivel
This ebook is licensed for your personal enjoyment only. This ebook may not be re-sold or given away to other people. If you would like to share this book with another person, please purchase an additional copy for each recipient. If you’re reading this book and did not purchase it, or it was not purchased for your use only, then please return to Smashwords.com and purchase your own copy. Thank you for respecting the hard work of this author.
########
For Tamara, Mazaryk, Draven, and Ryker
#######
Table of Contents
Why Work Breakdown Structure Training?
Why This is Not Like Other Books
About Josh Nankivel, BSc PM, PMP
Chapter 1 - What Is A WBS? What Is It Not?
Chapter 2 - Why Do I Need a WBS Anyway?
Chapter 3 - What Do I Need Before I Start?
Chapter 4 - How Do I Structure My WBS?
Chapter 5 - What Tools Can I Use For My WBS?
Chapter 6 - How Do I Actually Create A WBS?
Chapter 7 - How Do I Use My WBS?
Introduction
Thank you for your interest in one of the most fundamental project management tools, the Work Breakdown Structure.
Why Work Breakdown Structure Training?
In my career, I have seen many project managers and organizations limp along on projects in ways that were preventable with proper use of the WBS tool. I created WBS Coach to help combat this problem. In addition to this version, there are additional tutorial videos and audio resources available in the complete digital training package at http://WBSCoach.com. There is a discount on that course available to you as someone who purchased this book. See the final page of the book for your discount code.
I wrote this book for the new or aspiring project manager, the “accidental” project manager who may have no background of approaching project management as a formal discipline, and even the experienced project manager who is looking to enhance their ability to manage successful projects.
Why This is Not Like Other Books
Other project management “how to” books read like textbooks. My style of writing includes talking directly to you, the reader. I imagine that you and I are working for the same organization and are sitting together at one of our desks chatting about the topic. It may be helpful for you to imagine this same scenario as you read this book. I recommend you start at the beginning and read the chapters in order. Do not skip around because the lessons build on each other.
Since you have purchased this book, I will consider you my student for the time being. As such, you should feel free to contact me at josh@WBSCoach.com with your questions and feedback. It could be about this topic or project management in general. I also invite you to check out my free newsletters available at http://pmStudent.com. There are several to choose from and it is very likely one of them will fit your situation.
I realize that people learn and absorb new information in different ways. I have taken pains to organize this book in a manner that separate notes on your part should be unnecessary. At the end of Chapter 6 there is a WBS Checklist you can print out and use while implementing the concepts we will be discussing.
I have also tried to make it easy to refer back to this eBook when you need to. Have you ever noticed how many PDF files have a mismatch between the page numbers at the bottom of the page and the actual page of the file? If you want to go to page 112 and just type that into the page navigation box at the top, you end up on page 111 or 115. In this eBook, you will get to the right page by typing in the page number.
Additionally you can use the bookmarks toolbar to navigate through the chapters. I have structured this file so that all chapters and subheadings show up as bookmarks to make it as easy as possible to navigate.
See the image on the next page for an example of what I mean. It is a screen capture using Adobe Reader. I circled in green the various ways to navigate through the file. I especially like navigating via the bookmarks pane. You can open this by clicking the icon on the left that looks like a ribbon bookmark hanging over a page. Or you can use the top menu by clicking View >> Navigation Panels >> Bookmarks.
The next section is a little about me. Use this to get into that mindset where you and I are sitting at a desk having a discussion. It is important for you to be aware of my background so that we can have a good conversation throughout this book together. It will help you remember my lessons learned and the concepts we will discuss.
About Josh Nankivel, BSc PM, PMP
I have been managing IT and non-IT projects in Computing, Financial Services, Telecommunications, and Aerospace for over a decade. I have also been a team member on projects in both technical (as a database developer) and non-technical capacities, and I have been a project sponsor. I have worked on projects with a Waterfall approach, Scrum Agile, and various mash-ups including some elements of Critical Chain project management.
A
major theme throughout my career is process improvement projects. My
passion for processes has led me to lead many automation and
organizational process initiatives. I initiated a sizeable chunk of
these, as a sponsor or just a “concerned citizen” wanting to make
things work better. That passion also makes me constantly evaluate
my own project management processes and improve them on a continuous
basis.
I was a professional trainer for several years before
managing projects, and I love to teach. While working for Gateway
computers I earned several internal technical training certifications
and awards as a trainer before making the career switch to management
and project management. My academic background includes a Bachelor
of Science in Project Management and I am PMP certified.
I love
to write and speak about project management. My blog at
http://pmstudent.com/
has the goal of helping new and aspiring project managers learn about
project management and reach their career goals. You can find my
publications and interviews on dozens of sites and print
publications. I am an avid volunteer for several project management
organizations including the PMI New Media Council, past Vice Chair of
Special Projects for the Students of Project Management Specific
Interest Group (PMI). I speak from time to time at both large
conferences and local events on various project management topics.
I
live in Sioux Falls, South Dakota in the United States with my wife
and our three sons. Oh, and I am a science & technology geek
too!
Here we go!
Josh Nankivel, PMP
Project Management Best Practices Instructor
Chapter 1 - What Is A WBS? What Is It Not?
Remember a time when you had to do something that was so huge, so complex that you did not know where to start?
Many projects are exactly like this at the beginning. You only have a vague idea of what you are actually supposed to produce, and what it will take to make it happen. The Work Breakdown Structure (WBS) is essentially a special kind of outline, one that you use to plan and execute your project.
Have you ever started working on something and then kept having to change your plans repeatedly because of all the things you forgot you had to do?
Scope changes WILL occur on your projects, and you WILL forget to plan for activities and realize it very late. A WBS helps minimize these problems, and makes them easier to deal with when they occur.
Figure A - Illustration of WBS graphic structure
The WBS is an Outline
It is important to note that the WBS is an outline of the work; it is only intended to specify the WHAT, not the HOW. Just as in any standard outline, there is a level 1, level 2, level 3, etc. Each level decomposes the level above it in more detail.
The WBS needs to focus on outcomes (products or services) and not on tasks (how you will provide/produce them) or on resources (people and other resources doing the work). Do not go wrong with your WBS by trying to specify individual tasks with it. There are future steps where you will define individual tasks.
The WBS Consists of a Graphic AND Dictionary
You can represent a WBS in many ways, as long as it includes these two things:
A hierarchy of decomposition that is easily understood by the stakeholders on your project provides enough detail to accurately describe the WBS elements
Most organizations use a graphical representation of the WBS that looks similar to a company organizational chart. I have also seen the WBS in an outline format, and as a mind map.
The WBS dictionary is essentially just a collection of more detailed descriptions of the WBS elements. This is necessary because fully describing an element AND making it easily represented in a graphic format are two opposing goals. By using a numbering scheme and short title on the graphic and then providing more detail in a WBS dictionary, you get the best of both worlds.
I always include the WBS and WBS Dictionary in the same document. Never make your project team and stakeholders have to search for information. If they are looking at the WBS, everything the WBS holds should be easily available to them right there.
The WBS Defines Your Project
If a product or service is not on your WBS, it is not a part of your project. This outline of your project contains 100% of all the scope involved. Everything that is on your WBS is a part of your project. Therefore, at any time during the project you should be able to look at your WBS as the definition of all your project scope.
When someone requests a change at any time during the project (and they will), your first step is to go back to your WBS and see if this is really a change or not. The WBS graphic is a quick and easy way to help your stakeholders, sponsor, and project team understand what is and is not part of the project scope. It also helps them understand why you have to stop and go through a process to add new scope (or take some away) and why you cannot just “fit it in” after work has begun.
Do not forget about project services when defining your WBS. This should be its own distinct item on your WBS. Even if it is just your work as the project manager, it is critical to include it. The same goes for support services that the project will use and relate directly or indirectly to the product you are creating. You may want to create a WBS item at level 2 called “Project Services” and then at level 3 break these down a bit further.
Here are some examples of project services. Depending on the size and complexity of your project, you may not have all of these, or you may have even more:
Project Management
Asset Management
Configuration Management
Quality Management
Document Management
System Administration
Backups
Security
Administrative Assistant
The WBS Helps Everyone Understand
A great benefit of the WBS (especially the graphic version of it) is that it helps everyone who is a stakeholder in the project share a common understanding of the scope.
Different people are interested in different parts of the WBS. For instance, your CEO may only want to know what the high-level scope is. She wants to know what you are delivering at a 10,000-foot view. Your software developer is mostly interested in the lowest level. He wants to know exactly what he will be expected to write code for, and what functionality it should deliver. Your engineer may “live” in between, being responsible for the integration of various elements but not worried about the minor details or the entire project either.
Additionally, you may have separate teams that care about a particular branch of the WBS but not so much about the rest. If your project has 10 subsystems that all need to work together, the team responsible for developing 1 subsystem may not care too much about the rest of the subsystems except for the interfaces between them. You may have 1 stakeholder for 4 subsystems, another stakeholder for the others. These stakeholders care very deeply about status reporting for their own pieces of the project, but not pay attention to the rest.
The WBS is NOT a Task List
When I first began managing small projects, I used a task list to plan and remember what we needed to do. This is NOT a WBS, and it is not nearly as effective as a WBS either.
A task list has no levels of decomposition that clearly show how smaller pieces of scope will come together and produce the final output of your project. With a task list:
You will lose sight of what the scope of your project really is
You will not think of things that need to get done until you miss them “oh man, how did we miss that?”
You will lose out on all the other benefits a true WBS gives you
The level of rigor you go through will vary depending on your project size and type. I have managed projects that lasted only a few weeks, and I used a WBS for them. The WBS is less complex and smaller on simple projects, and can get very large and complex on large projects. Complexity and size of the WBS correlate directly to your product(s).
The WBS is NOT an Organizational Chart Perry looked me straight in the eyes. “What do you mean I cannot organize my WBS this way? It is my WBS; I can do whatever I want!”
“Very true Perry” I said. “It is your WBS and you can do whatever you want. I am telling you that organizing your WBS artificially, to align with your organizational structure is a mistake. You will regret it later.”
Perry decided to do it his way. I knew he would uncover missing work his team had not thought of. Why? Instead of being focused on the output of the project as a WBS should be, he organized it by one of the inputs, the resources doing the work. This takes the focus off the unique product the project is producing, and leads to unexpected omission of scope.
It can also lead to scope bloat! When you try to plan a project this way, scope can creep in that is not really a part of the product you are producing, and/or is not necessary to meet the requirements for your deliverables.
The WBS is NOT Time-Phased
When you create a WBS, you will be tempted to organize it in phases. During the brainstorming process I will cover later, you will find it natural for people to think of work through time. “After we get that done, the next step will be…” This is fine. When building a WBS I find it naturally tends to be in rough chronological order left to right, which is handy since the numbering scheme will probably go from left to right as well.
Some people say it is OK to organize your WBS by the phases of your project. In fact, the PMBOK Guide 4th Edition even has a graphic illustrating a WBS using phases for level 2 organization. I disagree with this approach completely. I have seen how this kind of project planning can lead to unstated assumptions and missing scope in your WBS. Again, you must focus on the unique product that your project is delivering in order to capture all of your scope in the most complete way.
There is a difference between organizing your WBS by phases and having some general chronology. For instance, System A may need to be developed before System B can be started, so your level 2 WBS items could be “System A” and “System B” and be in left-to-right order. That is fine. If you put “System B” before “System A” that would be fine too. It may be more convenient to have “System A” be your 2.0 element and “System B” be the 3.0 element just for aesthetics, but not necessary.
What is NOT fine is to organize your WBS by “Phase 1” and “Phase 2”. Phases are not deliverables or services, they are time periods.
What is a WBS? What is it NOT?
Chapter 2 - Why Do I Need a WBS Anyway?
Now you have a general idea of what a WBS is, if you did not already. Let us talk about something else that is very important before we jump right into more chapters and tutorials about how to use the WBS tool.
Let us talk about WHY you want to use the WBS. Many times, people do a WBS because they “are supposed to”. If you do not understand exactly why a WBS is so useful on your projects, you will never use it to its full potential. And that would be bad. It would also be reflective of how most project managers treat their WBS, if they use one at all. Let’s do better than them. Let’s be the group who uses a WBS on every project AND gets the most out of it.
The WBS is the Foundation for All Future Activity