Project Seminars

Creating the Work Breakdown Structure

The WBS is a decomposition of the project scope statement. It is a deliverables-oriented document that visualizes all the things the project will create. It is not, and I stress the word not, the activity list. The WBS takes the project scope statement and breaks it down into the deliverables the customer is expecting from the project. It organizes and catalogs the project deliverables.

The smallest item in the WBS, that is the lowest decomposed deliverable, is called the work package. I know what you're thinking (maybe). If the WBS is not about activities then why is it called a Work Breakdown Structure – and why is the smallest element a work package? Good question! When we think of "work" we often think of labor – like I'm working on a report. Work can also be a noun – like the works of Mozart or the works of Picasso. When it comes to the WBS you should think of work as a noun rather than as a series of activities.

The process of creating the WBS should involve the project team and the project's key stakeholders. Yes, the key stakeholders should be involved in creating the WBS. It's important to involve the project stakeholders, as this promotes additional project buy-in and it helps the stakeholders see the depth of deliverables that are included as part of the project.

The Last of the Scope

Here are the last items you'll want to include in your project scope statement:

Cost estimate. Everyone wants to know how much your project will cost. The cost estimate and the supporting detail for that cost estimate is included in the project scope statement. I’ll address the process of creating a cost estimate in just a bit. I promise.

Project configuration management requirements. Remember the phrase “features and functions” and the product scope? This section of the project scope statement defines the level of control the project manager (and often by proxy the organization) will place over the project change control requirements. Changes to the product scope will result in changes to the project scope.

Project specifications. This section of the project scope statement identifies any of the specification documents such as regulations, requirements sheets, blueprints, or the like that the project must comply with.

Approval requirements. Someone, an individual or a committee, must sign off on the project when it’s completed. This section of the project scope statement defines the requirements for the project to be approved.

The project scope statement is a cornerstone of the project. It serves as a guide for all future project decisions, and the project manager and the project team must protect the scope from unapproved changes as the project moves through execution. The project scope statement is the written version of what’s commonly called “the project scope” or just “scope.”

Keep Building Your Scope

Here are three more things you'll want to include in your project scope statement:

Initial defined risks. A risk is an uncertain event or condition that may have a negative (or sometimes a positive) effect on the project. I’ll talk a bunch more about risks later in this section. Hold your horses!

Schedule milestones. A milestone is a non-timed condition or event that shows that the project is making progress. For example, finishing the foundation could be a milestone. Milestones often end a phase of the project and allow the next phase of the project work to begin.

Fund limitation. Unless you work for some wonderful organization, your project is going to have a funding limitation and a reconciliation process to identify where the monies for the project have gone.

More Stuff For Your Scope

And here are three more things to put into your project scope:

Project constraints. A constraint is anything the limits the project manager’s options. You must be done in two years. You must not exceed four million dollars. You must use COBOL. You must use Indiana limestone. Anytime you see the word “must” or “demand” then you know you’re dealing with a project constraint. Technically, all projects have at least three constraints: time, cost, and scope.

Project assumptions. An assumption is anything that you believe to be true, but you haven’t necessarily proven to be true. For example, in construction an assumption is often made that summer months are better than winter months for building. Or you may assume that the software you’re creating will work just peachy with Windows Vista. Or you assume that all of your project team members are happy to working on your project. As you can imagine, assumptions can become risks.

Initial project organization. Who’s who in your project. This portion of the project scope statement defines the project manager, the project team, the project customers, and any other project stakeholders. You may also identify the reporting structure in this portion of the project scope statement.

Scope Checklist: Items 4, 5, and 6

There are 16 items that a project scope statement should include, here are items four, five, and six:

Project boundaries. These are things that are considered out of project scope. For example, we’ll create and compile the new software for you, but we will not create the CD image and ship the software around the world for you. A project boundary may also identify areas where the project should not overlap with other lines of business or projects. For example and electrician may have a boundary created for him to install the high-voltage wiring, but not the low-voltage wiring – such as network cable and home security systems.

Project deliverables. Isn’t this obvious? It’s the product that the project will be creating. But wait a minute professor, there’s also ancillary deliverables – the project documentations, the project management plans, the project communications, contracts, and all the other historical information the organization reaps as a result of the project. Bonus!

Product acceptance criteria. You want it when and it has to do what? Easy enough – it’s the criteria the project manager and the project customer both may use to determine the success of the project.

Scope Checklist: Items 1, 2 and 3

So what exactly does a project scope statement include? I’m glad you asked, otherwise this list would be just silly. There are 16 items that a project scope statement should include, here the first three:

Project objectives. Objectives are the goals of the project – the measurable, quantifiable goals of the project. Think of time, cost, quality, technical requirements, blueprints, and product acceptance criteria. I stress the word quantifiable – avoid loose terms in your objectives such as fast, good, satisfaction, and other subjective terms. What’s fast to you may be slow to your customer. If you can attach a metric to it you need to.

Product scope. Remember the product scope – the vision of what the project will create? The product scope and all of its features and functions are included here.

Project requirements. Let’s face it, your project will have some requirements. You can identify a project requirement as anything that “must” be met, kept, or deliverabled. The project must not exceed $750,000. The project deliverable must be able to interface with SQL, Oracle, and Access. The project deliverable must be blue. Requirements are often, if not usually, tied to the product scope and the project objectives.

Detailing the Project Scope

The project scope statement is a document that defines what the project is, the project deliverables, and the work that the project team (and likely contractors) will have to do in order to create the identified project deliverables. The major purpose of the document is to communicate with the project team, the project customers, and the project stakeholders a common understanding of the project’s purpose, goals, and objectives. The project scope statement, as I’ll dive into one moment, also serves as a launching board for additional planning by the project team and the project manager.

The project scope can be a large document or a simple one or two-page manifesto. So how big does this thing have to be? Here’s a heuristic you can rely on: larger projects typically require more detail than smaller projects. In other words, the bigger the project the longer it’s going to take to create the project scope statement, and the more information you’ll need to include in the document.

Real World Note: I admit I’m painting some large brush strokes here. Most organizations are going to have project scope statements available from past projects – that’s part of your organizational process assets. There’s nothing wrong with using a past project’s documents as templates for your current project – work smart not hard. And if your organization has never, ever completed a scope statement before? You’ll need some additional planning time to create the project scope statement. Don’t be surprised if your project scope statement goes through several rounds of revisions – it should.

Asking for Help

I don’t like to ask for help. I’ve always, from when I was a little twerp, through college, and into my adult years, resisted the urge to ask for help. I’ve had an I-can-do-it-all-buster attitude. I saw asking for help as a weakness. I saw asking for help as something other people did when they weren’t able to accomplish things on their own. Ask for help? No way.

One of my earliest memories is my brother Steve trying to help me tie my shoes. I got so mad because I wanted to do it on my own, but I couldn’t. Steve finally, tired of my crying, pushed me back and tied my shoes for me. And I didn’t like it. I wanted to do everything my way or no way.

I think this stubborn attitude is one of the reasons I’m a writer. Writing is a pretty solitude life and I can to do pretty much whatever I want. Want to write about stinky socks in the microwave? Go right ahead. Want to write about – Yawn! – business analysis? Yeah, sure, that’ll work. Certainly there are editors that reel me in, but they pretty much let me do what I want.

But doing things my way – our way – isn’t always what’s best. Probably many of you have learned this lesson a long time ago, but not me. I had this belief that asking for help makes me look vulnerable. The truth is that asking for help is really about taking charge. Asking for help is me recognizing that I have limits, can’t do it all, but I can make choices to overcome the limits and still get the work done. Asking for help is vulnerability – it’s empowering.

Another belief I’ve held onto is that successful people just don’t ask for help. Did Ted Turner, Chris Whittle, Carol Bartz, or Ann Bartlett never ask for help? I bet they did. I’ve learned that asking for help is about recognizing your strength, weaknesses, opportunities, and threats (SWOT) and then acting accordingly. Asking for help is smart.

Will you help me?

Tell me, honestly and directly, how can I make this blog better? Are there features, content, or topics that I’m not addressing that I should? What would you like to see more (or less) of? How can I increase readership, traffic, and share this message with more people? You can share your thoughts directly in the comment section or email me jdp (at) lifelongproject.com.

Thanks for your help!

Finalizing the Project Scope

Another tool the project manager can use to create the project scope statement is alternative identification. Alternative identification, just like it sounds, is a method to identify any other solutions, approaches, or deliverables that would satisfy the customer’s product scope. For example, a customer wants an email server. They don’t care if you use Microsoft Exchange Server or some home-grown POP3 mail server. All they want is an email server that allows their staff to send and receive email. Alternative identification would identify, compare, and contrast all the available solutions for the customer.

Finally, the last major approach, and probably the most realistic is stakeholder analysis. Stakeholder analysis involves the project manager, the project team, and often business analysts to interview the project stakeholders to create the project scope. Some folks call this process requirements gathering, and that’s fine, but it’s more than just understanding the requirements for the project. It’s also identifying quantitative metrics, conditions for project acceptance, and working with the project stakeholders to create a project buy-in and shared ownership of the project.

Real World Note: Involve your stakeholders. When I consult I often see an “us-against-them” mentality between the project team and the project stakeholders. I want to scream when I see it – and it’s not hard to recognize. Your project customers, your key stakeholders, and the recipients of the project should work together in harmony. It’s up to the project manager and the project team to facilitate that harmony.

Twice the Fun: Two Scopes

Technically there are two scopes when it comes to project management:

Product scope – This is the vision or expectation of what the customer has in mind for you to create for them. For example, imagine your dream home; in your mind’s eye you can probably see your house, the material is made out of, the kitchen, the den, the bedrooms, and so on. You can probably also imagine how you and your family would use and live in the home. This is the product scope – all of the features and functions that the project is to create for you, the project customer.

Project scope – This is all of the resources and work required to create the product scope and the ancillary deliverables of the project. This the labor, plans, blueprints, documents, and effort to create the vision the project customer possess.

The product scope and the project scope support one another. If the project team is doing work outside of the project scope then the customer is not going to get the product scope that she envisioned. If the customer doesn’t know what the product scope is then the project manager and the project team are going to have a tough time creating the project scope. These two scopes support one another. The project scope statement is identified by completing a product scope analysis, since it reveals what the project must create.

Real World Note: Often the product scope is already designed before the project manager and the project team get started on the project. The product scope is concerned with the features and functions of the project deliverable, while the project scope is concerned with the work to create the project deliverables.