One lady, we'll call her Ms. Rite, insisted on following me around her yard as I mowed. She complained about the height of the mower, the way I bagged the grass, and the way I tied my sneakers. In addition to mowing the lawn, this princess also hired me to pull the weeds, rake the leaves, trim the shrubs, clean out the gutters, and tons more—depending on the weather and when her coven was meeting.
It wasn't that I didn't want to do all those chores—it was the constant comments and the addition of activities as I completed what was agreed upon. For Ms. Rite, cleaning the gutters could easily have stretched into installing new shingles. Planting a small tree could have stretched into installing an in-ground pool. To her, a deal wasn't a deal unless she got her 20 dollars worth. I dreaded every project I did for her because I knew that she'd change the activity as soon as "we" got started. Oh the joys.
The one thing I learned from this demanding customer was that you must have clearly defined requirements for acceptance before you begin. If only I had learned this lesson when I was 14, I could have bought a few packs more of baseball cards. When Ms. Rite hired me to pull weeds, I could have stressed that the job meant the weeds that were visible around her yard—not the ones that might be in the crawlspace or that might pop up overnight.
If I had known then what I know now, I would have defined the scope.
Defining the Project Scope
In project management (and to some extent in lawn work), there are actually two different scopes. The first is the product scope, which is what the end result of the project will create. The product scope is what customers focus on—what they are envisioning for you to create. The product scope describes the thing or service that will exist as a result of your project.
The project scope, on the other hand, describes all the work to create the product scope. It includes all of the work, and only the required work, to complete the project deliverable. In my lawn-work experience, the product scope could have been summed up as a manicured lawn suitable for a photo-op for Home and Garden magazine. The project scope would include the details on how to get there: Mow the lawn, pull the weeds, trim and edge the property, and edge the shrubs.
The project scope and the product scope support one another. In the IT world, if you're creating an application for a stakeholder, they have expectations of what the application will do. When they discuss the requirements with you, they describe the end result of the application. Stakeholders think in terms of the vision, of the product existing. They can see into the future and experience the application before it's created. Stakeholders usually have a way of seeing the problem solved and the organization with their solution, and can feel a sense of relief and urgency to get the deliverable into production.
Unfortunately for project managers, some stakeholders don't have this gift. Their approach to requirements-gathering is more like Ms. Rite. They don't know what they want until you're doing the work. These stakeholders have a common mantra: "I don't know what I want, but that ain't it." These are fantastic and joyous times for a project manager (that's sarcasm, of course).
The goal of requirements-gathering, for those of you who've not experienced these wishy-washy stakeholders, is to define exactly what the project will create. For most people, it makes perfect sense; if you don't know what the project is supposed to create, the project will fail.
Sometimes this isn't the stakeholder's fault; sometimes it's really the project manager's fault. If the project manager doesn't capture the same vision that the stakeholder has for the end result, he's setting himself up for failure. I know some project managers (and I bet you do, too) who have come up through the ranks of IT. Their background is in technology, they are technological geniuses, and they can configure Novell servers to make toast. The trouble is, some of these folks don't take the time to listen to what the customer is really asking for. They don't take the time to capture the product scope. They can't see the end result that the customer sees.
The technical project managers gravitate toward a solution that solves the problem they think they understand rather than the problem the customer has. We don't really need technical project managers. Let me write that again so you don't think it's a typo: We don't need technical project managers.
What we need are project managers who can capture what the customer wants. We need project managers who listen to customers describe their vision of what the project will create. We need project managers who can listen, query, research, and revisit the problem that the stakeholder needs resolved. Or who can work with the customer to ensure that the project will seize an opportunity. Or who can rely on their project team to create a solution that does both. Technical project managers are great, but I'll take a project manager who listens and understands the project purpose any day.
If you get nothing else out of this article, get this: You cannot—must not—begin a project until you know the requirements for acceptance. We see this all the time: You wouldn't build a house without knowing what the house will look like at completion. You wouldn't create a call center without describing the purpose and features of the call center. You wouldn't create a car without specs on what the car should have. I understand that technology is fluid, and that as IT project managers we have to be able to adapt and evolve, but we must have some clear specifications of what the deliverable should be before we commence the project. Without a clear vision of the project deliverables, the project is doomed.
Documentation Means Everything
After the project manager and the customer are in agreement about what the project will create, the project manager should create a scope statement, which is a document that captures everything that is considered in scope and defines the relevant things that are out of scope. For example, a project to push an application to 1,500 workstations might define the application, define the overview of the project work, and emphasize that the rollout doesn't include visiting every machine to confirm the existence of the push. The scope statement clarifies the project and requires the project manager, the project sponsor, and sometimes the key stakeholders to sign off on the document.
The scope statement serves as the guide for all future project decisions. The following figure shows the timeline of the project and the relevant influence of the project manager and the stakeholders. Early in the project the stakeholders should have a bunch of influence—their input is essential. As the project progresses toward completion, notice that the stakeholders' influence wanes as the project manager's influence increases. The intersection of the two paths represents the creation of the scope statement.
In other words, once the scope statement has been agreed upon, the project manager owns the project and works to protect and deliver on the promises established in the scope statement.
Creating the Work Breakdown Structure
Once the scope statement has been written, it's time to break down. Well, not you, the scope. A Work Breakdown Structure (WBS) is a deliverables-oriented decomposition of the project. It is not the activities needed to create the project deliverables; it's the stuff that the activities create.
Gasp!
That's right. A WBS is not the work, but the deliverables. Some folks in the IT world (I won't mention them by name, but their initials are Microsoft) have skewed this a bit. If you've ever used Microsoft Project, a great tool, you may have been led to believe that the activity list, the default view in Microsoft Project, is the WBS. It isn't so.
A WBS is not the activities but the actual deliverables that the customer expects from the project work. Suppose that we were going to install a network from scratch in five different locations around the country: northern California, Tacoma, Philadelphia, Atlanta, and L.A. We'd have some major categories of things for our project:
1. WAN
2. LAN
3. Operating systems
4. Education
These major categories of things can be broken down again to more things that we'll be delivering in the project:
WAN LAN Operating Systems Education
ISP contracts Switches Workstations IT professional education
Routers Switches Wall jacks End user education
Servers LAN addressing schemes IP addressing schemes
WAN diagram Patch panels
See how the deliverables are decomposed into more things? We're decomposing the project scope into things that the customer will get as a result of the project. Stuff, not activities. The end result of the WBS is a clear picture of what the customer will and won't get as part of the project.
So how far should you break down the project deliverables? You could (not that you'd want to) decompose your WAN deliverables down to the nuts and bolts in the rack that'll house the hardware.
You want to follow the "8/80 Rule" when you break down your project scope. The 8/80 Rule, which really isn't a rule but a guideline, requests that the smallest deliverable in the WBS, called the work package, equate to no more than 80 hours of work and no fewer than 8 hours of work to create that deliverable. You don't want to get so granular or so vague with your WBS that it's uncontrollable and useless.
But why even bother creating a WBS? There are a bunch of reasons why an accurate and complete WBS needs to exist, but there are five prominent reasons why every project needs a WBS (discussed in the following sections).
Cost Estimating
Because a WBS requires you and your project team to account for everything you'll be creating, you can create very accurate cost estimates of what the project will cost to complete. This estimate, which comes a bit after your rough order of magnitude estimate (ROM), is called the definitive estimate, and it is the most accurate. You may know ROM estimates referred to as hallway estimates or ballpark estimates.
Cost Budgeting
Cost budgeting is the actual money committed on a project deliverable. Once the cost estimate has been created, we have to track the actual time and materials expenses that went into creating the WBS deliverable. The difference between what was estimated and what is actual is the cost variance. Cost budgeting allows the project manager and management to track the cost baseline of the project.
Resource Planning
How do you know how much help you'll need to complete the project? Most project managers rely on expert judgment, experience, and gut feelings, but the WBS reveals the deliverables and the required talent to create the deliverables. For example, in our WAN/LAN project, one of our deliverables might be Cisco routers. This deliverable might require us to hire or contract a CCIE to configure our network.
Risk Management Planning
Risk is an uncertain event that can have positive or negative effects on our project. The WBS allows us to consider the circumstances and conditions of each deliverable for risks within our project. Once we've identified the risks, we can then shovel them through qualitative and quantitative analysis to capture which risks we need to mitigate and which ones we can live with.
Activity Definition
Sigh of relief, right? Once we have the WBS created we can then define the needed activities to actually create the deliverables that the customer is waiting for. We need to identify all the deliverables that the project will create so that we can identify all the activities to create the project.
Decently and In Order
Sometimes new project managers get frustrated at all these processes and extra procedures, and just want to get to work. Rookie mistake. Projects, well...successful projects, follow a proven system to get to the execution of the project plan. If there were a Robert's Rules of Order for Project Management, the precedence of all this activity would go something like this:
1. Get a project charter.
2. Create the project scope statement.
3. Create the WBS with the project team.
4. Create the activity list from the WBS.
5. Sequence the activities in the order in which they must—or should—happen.
6. Estimate the time of the activities based on which resources you have to complete the activities.
7. Assign the needed resources to the activities.
8. Get it done.
Of course, that's a quick summation of how the project team gets to work in a perfect world. I realize that it doesn't always go this way; in the real world, projects often fail.
Once the scope has been defined, the WBS has been created, and the customers sign off on both documents, the project manager wants to lock down any additions or changes. This is scope change control. How many projects have you worked on where the customer bangs on your door every day with a few hundred changes for the project deliverable? Okay, maybe they don't bang on your door every day, but I bet they pop in with some "oh-yeah moments." Or they're so impressed with the good job your team is doing that they realize you could easily work in a few more details for them. Right?
Oh the horrors.
Once a project scope and WBS have been agreed upon, it's up to the project manager to ensure that the project team and the customer that changes won't easily be allowed into the project. The only way this is going to work is if the project manager communicates to the customer the documented and tightly followed Change Control System (CCS). A CCS serves as a shield from unnecessary and bloated changes. It requires the requestor to document the change request, why the change is needed, and the ramifications of the project deliverable if the change is denied.
From the requestor, the change is promoted to the manager, project sponsor, or directly to the project manager. Eventually the change may be promoted to a Change Control Board (CCB) where some cheery folks will debate the value and worthiness of the proposed change, and can elect to decline or approve the proposed change.
Any change that is seriously considered must have plenty of research to determine the influence of the change request on the rest of the project. At a minimum, the change must be evaluated for the following attributes:
· Ramifications of declining the change request.
· Risk of accepting the change.
· Cost and time to include the requested change.
· Effect of the change on the project quality.
· Effect of the change on any procurement decisions, contracts, and financials.
· Effect of the change or series of changes on the project team's ability to complete the project on schedule.
· Effect of the change on the project team's morale.
· Effect of the change on the project manager's chances of a promotion or bonus. Kidding.
Like it or not, some changes are great for the project deliverable, and it just makes sense to include them in the project scope. Other changes—again like it or not—will not be good for the project. All changes, good or bad, need to be documented and researched. This takes time. A flurry of change requests, even if they are all declined, will usually pull the project manager and/or the project team away from their focus of getting the project work done. A documented and working CCS is mandatory for any organization.
So how do you know when the project is done? Some would say when you run out of money or out of time. To some extent, that's true—if the planning has been done accurately, the project should end on time and with no remaining funds. But this is supposed to be a realistic discussion on project management.
Projects are finished when the project scope has been completed. A project is complete when the project scope equates to the present state. A project is complete when the project manager and the project customer can take the WBS and check off each item like last week's shopping list. This is scope verification.
Scope verification is simply the project manager and the project customer inspecting the project deliverables to ensure that all the promises in the project plan exist in the project deliverable. There may be some rework, corrective actions, or last-minute change requests to complete the project; if all goes according to plan, the project manager and the customer are in agreement that the deliverables equate to the project scope.
This takes time.
Whether you're managing the creation of software or building a new four-bedroom home, there is usually a window of opportunity for the customer and the project team to continue to work together to ensure that the deliverables are good and working as planned. This can be through a service agreement or a warranty. The bottom line is that most major projects have a certain amount of time allotted for the customer to use the deliverable and to report any problem to the project manager for corrections or support.
This business needs to be defined upfront; it cannot be left to assumptions. It's no fun when the customer assumes that you and your project team would be supporting the deliverable for eternity when you assume that you'll be supporting the deliverable for the next three months. No fun at all. A clearly defined Operational Transfer Plan, warranty, or agreed level of service must be defined early in the project. And then stick to it.
If only I had known all this business back when I was sweating out lawn work for Ms. Rite. Scope management, big or small, boils down to agreeing on what the project will and will not deliver. Then both parties must live by the agreement. After all, a deal's a deal.
Business 
