Project Scope

9 Gantt Chart

Screen Beans Art © A Bit Better Corporation used by permission under license

The "knowledge area" of Project Scope Management includes processes in both Project Planning and Project Monitoring and Control. Any way we look at it, scope is about requirements, and defining project requirements and scope is one of the first things we must do in a project.

"Even perfect program verification can only establish that a program meets its specification…. Much of the essence of building a program is in fact the debugging of the specification."

-- Frederick Brooks, The Mythical Man-Month, 1975

"The essence of a software entity is a construct of interlocking concepts: … I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation."

-- Frederick Brooks, developer of OS/360 "No Silver Bullet: Essence and Accidents of Software Engineering" 1986

"The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstract away its essence."

-- Frederick Brooks, developer of OS/360 "No Silver Bullet: Essence and Accidents of Software Engineering" 1986

"Einstein repeatedly argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer. Much of the complexity he must master is arbitrary complexity … because they were designed by different people, rather than by God."

-- Frederick Brooks, developer of OS/360 "No Silver Bullet: Essence and Accidents of Software Engineering" 1986

"Nothing is particularly hard if you divide it into small jobs."

-- Henry Ford

"The secret of getting ahead is getting started. The secret of getting started is breaking your complex overwhelming tasks into small manageable tasks, and then starting on the first one."

-- Mark Twain

"Start by doing what's necessary; then do what's possible; and suddenly you are doing the impossible."

-- St. Francis of Assisi

I can't say enough about the importance of clearly understanding and defining user/customer requirements. If we don't know what the sponsor wants, we'll end up doing something else.

This is actually one of several major themes or threads that recur throughout project management and this course:

Everything depends on the user's requirements.

Oddly enough, it is all too common for customers to be quite vague and cursory about what they want. Don't get me wrong, they'll recognize it when they see it. So if we have an infinite budget and time is of no importance, we can keep trying, guessing, and building systems until we happen to hit on what they like. You say your budget isn't infinite and you actually have a delivery deadline? Oh, well; can't take that approach, then.

Why aren't customers clear about what they want? Several reasons, including, among others:

· They know their business, and hopefully their business needs, but they don't know IT. That's not their business. So they have no definitive knowledge of what IT can and can't do for them, nor how difficult or expensive it will be to deliver. Unfortunately, the techies don't know the customer's business, needs, or requirements. That's not their business and they can't successfully guess. It will only work if all involved work closely together to determine the requirements -- customers, users, techies, developers, project managers, and all.

· Techies, especially programmers, are used to doing things in nit-picking detail. They have to, in order to write software. (See "The Woes of the Craft" in LEO Course Content.) Business people, users, and non-techies, however don't live in that world. They live in a world where they understand on a high level what they need to do, but probably haven't thought about the detailed steps necessary to make it happen.

Perhaps in an IT or systems analysis course, you've tried the exercise of writing down in everything you do to get out of bed, get ready for work, drive to work, and get to your office or workplace … in enough detail that it could be successfully executed by a Martian who knows nothing about Earth or how things work here. That's what it's like to analyze and set out the details for a program to do something.

Business users don't think like that. They leave a lot to assumption, but the techies can't know that.

· There's almost always iteration involved. It turns out that it's quite often simply not possible to know what all we need until we experience what we get. For instance, when they deliver a system and we use it, only then can we say something like, "Oh! Well then could you add up that column, too, and give me a total?" Until we got the list of data that we never had before, we couldn't know that we need a total also. That's a very simple example, but much more complex requirements usually come "out of the woodwork" that way. Techies may get frustrated and say, "Well why didn’t you tell me that in the first place! I could have done that, but now I've gone and built the system in a way that precludes that just because I didn't know." The thing is, the customer didn't know, either -- and could not possibly have known.

· We hear a lot about software defects ("bugs") and the cost of eliminating them (debugging). At each stage, it costs about 10 times more to eliminate defects introduced in an earlier stage than it would have cost to avoid them in that earlier stage in the first place.

As long as people live, they grow and change. Similarly, as long as businesses operate, they change. If they don’t, they won’t survive long in the changing marketplace. And as long as businesses change, requirements and scope will change. What’s more, there is an iterative, adaptive dynamic to systems use. Before the system is developed, users cannot imagine the full scope of capabilities it could have, and developers cannot know all the uses the users might put a system to. After it is in use for some time, the users can begin to see the possibilities and can say, “if only it could also do this….” We always say that a sufficiently large or complex system may take a few hours or days to learn, but it takes 12-18 months to really make it hum. That is because of this adaptive, iterative, learning factor. This is a major factor generating adaptive maintenance. But what if the changes come before system development is complete? In that case, such changes are a major factor in generating scope creep. (There are other causal factors as well, of course.) Unfortunately, scope creep costs, and costs dearly.

Oddly enough, organizations all too often don't give it what it deserves. Rather than spending the time and effort to figure out what their needs and requirements are, they think they can either contract it all out and have the contractor tell them what they need (at best, that's the tail wagging the dog; at worst, it's doomed to failure), or they think they can figure it out on the fly as they go (we don't know what we want, but we'll recognize it when we see it). Either way is going to be horribly expensive and horribly slow, if it ever results in a working system at all.

As a project manager, don't let the sponsor or stakeholder do this. We need to take the time, effort, and money to figure out what is needed before we build it or contract it out.

How's that Kenny Rogers song go? "You got to know when to hold 'em, know when to fold 'em, know when to walk away and know when to run"?

When do we fold 'em? When do we walk away? Sadly, one of the PM's responsibilities (and the sponsor's, too) is to kill bad projects. This is anathema to a project manager, because the PM's whole mid-set is to move heaven and earth to do whatever is necessary to bring the project in on time, on budget, and meeting requirements.

Some projects, however, are going down the tubes. Some are so far over budget or so late that they'll never come close and are just wasting time and money. Some have such technical difficulties that they can never meet requirements. More to the point of this chapter, however, some projects have such ill-defined requirements or scope, or have so much scope creep. The PM should be so aware of project status that he gets an advance warning of all such problems and is not blind-sided or caught by surprise. (The PM must also keep the sponsor and stakeholders informed.)

If the project can be salvaged, wonderful! If not, however, the PM then needs to kill the project before more resources are wasted. If the PM doesn't have the authority, or if it's shared authority with the sponsor (e.g., in a functionalized or matrix organization), then the PM needs to bring it to the attention of the sponsor or the powers that be and recommend cancellation.

Most contracts have "mandatory" and "desirable" requirements. That's a good way to look at project scope requirements, too. Mandatory requirements are those that the project simply must include or it won't function, won't do what it's intended to do. Desirables are requirements that will be weighted (and often rated), usually based on some sort of point scale. That does not mean that desirables are merely "nice to have". They may be vitally important, in which case they will be very heavily weighted.

In contracting, if a bid or offer omits even a single mandatory requirement, then it is automatically disqualified, even if everything else in it is absolutely wonderful. If we greatly like this offeror's bid because of the other good things it includes, we nevertheless cannot accept it if it is missing even a single mandatory. If that is the case, we may have made some things mandatory that really shouldn't be.

Because of this, the way I look at is that the mandatories are essentially there to weed out the impostors. If an offeror can't even do the mandatories, then it probably couldn't perform the work anyway and probably doesn't understand the problem. It's as though we wanted our portrait painted and a house painter said sure, I'll paint your portrait; do you want latex or oil based? Should I use a roller or a spray gun? Obviously, that painter didn’t understand what we wanted and couldn't do it successfully. (More on all of this in the unit on project procurement.)

Now, as Bill Cosby used to say in one of his routines, "I told you that, to tell you this:" It's similar for project requirements. Mandatory requirements in project scope are those requirements that are so critical that if they're missing, the product that the project produces will be worthless. Even if it has everything else and it's all wonderful, if it's missing a mandatory scope requirement, it can't possibly do it's job and it isn't really a system to do whatever is intended.

Once the mandatories have weeded out the impostors, the weights of the desirables will be used to prioritize the rest of the scope requirements. Not all requirements need to have the same weight; in fact, they should not have the same weight. So the important requirements are heavily weighted and the less important requirements are lightly weighted.

Ideally, it won't matter much, anyway. Ideally, the project will provide all the requirements on time and under budget. But if worst comes to worst (or is it "worse comes to worst"?) and something happens (and "something" often does), then the weighting system can be used to plan the sequence of scope deliverables. In other words, the most important scope requirements can be delivered first, and the less important ones can be delivered later. And if worst comes to worst, then if anything has to be dropped (which should only happen with careful negotiation with the stakeholders), then it will be the least important requirements that can be dropped.

If requirements are not prioritized, then it's much more difficult to do this -- and the negotiation is much more difficult on what to do if the funds run out, the budget is spent too fast, or the project runs late.

In most of life, it's exemplary to go above and beyond the call of duty. In project scope, it may not be.

Throwing in something extra and adding un-needed bells and whistles aren't actually good things in project scope. They can cause (or lead to) scope creep. Even if they don't, it takes resources to do them -- resources that could have been better used to deliver what is required and agreed upon, resources that could keep the project on schedule and within budget, resources that shouldn't be spent on things that were not wanted.

If we find ourselves at the end of a project with time and resources left over, then we're heroes! That's a good thing -- and is all too rare. That is much better than finding ourselves at the planned end date with the project unfinished and the budget gone. That is especially chagrining if that happens and we wasted our resources on gold-plating and bells and whistles that weren't needed in the first place.

Suppose it actually happens. Suppose we actually finish with time and money left over. In that case, we have some options. We can return the money to the customer and we'll be seen as heroes. We can negotiate additional features to add using the remaining resources. We'll probably still be heroes for doing that. (We have to be very careful in negotiation, however, to make sure that we don’t promise more than the resources can produce. We also have to be careful lest we find that re-starting parts of the project to modify what we've delivered may cost more than doing it in the first place.) There may be other options as well, depending on the nature of the project and of the customer-client relationship.

A Work Breakdown Structure (WBS) is not a product breakdown structure or PBS (that would essentially be a bill of materials or BOM), nor is it an organization breakdown structure (that would essentially be an organization chart), nor is it a cost or resource breakdown structure (that has various accounting terms like elements of resources or elements of expenses). A WBS, on the other hand, looks not at the objects themselves (products, deliverables, etc) at the work needed to produce those things. As such the items in a WBS should not be nouns, but should be phrased in verb-object form (e.g., not "3rd Prototype", or "3rd Prototype Development", but "Develop 3rd Prototype", etc.). After all, doing work is an action, a verb; and a verb action needs an object to act upon. Hence, the verb-object form of WBS entries.

A WBS shows work and may (and usually does) have durations associated with each task, and often has resources (either costs or staff) associated with each task. Strictly speaking, however, a WBS does not have predecessor-successor links, dependencies, or relationships between tasks. It is just a list list -- a list of the work tasks that make up the project. Once a WBS has durations added, as well as dependency links it is, strictly speaking, a schedule. In practice, however, we generally interchangeably refer to a WBS with linkages as either a WBS or a schedule. Most PM software packages do, too, though somewhat inaccurately.

If the tasks, taken together, accomplish everything that needs to be done to accomplish the project as a whole, then the WBS has fulfilled its purpose. If the tasks that are listed in the WBS are insufficient to accomplish the project -- if something is missing -- (or, for that matter, if they include extraneous work not related to the project), then the WBS has not succeeded in its purpose.

"Work packages" are the smallest, lowest-level "leaf node" of the WBS that are not broken down further. They need not all be at the same level.

They should be small enough to estimate, manage, and control relatively easily, but large enough to let the person tasked with executing them determine how they should be done. If they are smaller than that, then we're micromanaging and are also spending more time, effort, and cost on management than the tasks deserve. If they are larger than that, they will be difficult to estimate, manage, and control.

A common rule of thumb is that a work package should be not less than 2 days nor more than 2 weeks. If it's less than 2 days, we're micromanaging. If it's more than 2 weeks, they'll be difficult to estimate, manage, and control. For moderate size and larger projects, the work packages should be larger (tending toward 2 weeks); for huge, multiyear, hundreds-of-millions-of-dollars projects, they could even be a month or more; for smaller projects running for just a few months or less, the work packages would be smaller, tending toward a few days. The goal is to make the work packages a useful size for monitoring, controlling, and managing, not micromanaging.

Ideally, each work package should result in one deliverable and should be synonymous with an accounting "control account" or "planning package". The PMBOK treats work packages, control accounts, and planning packages as distinct entities that may not be synonymous. However, it is much easier to manage (and to estimate) if they are identical.

Include the Work to Manage the Project

Project management is work, too. So when developing a WBS or a schedule, make sure to include tasks that encompass the project management work to manage the project. For instance, we will be developing a project charter, a project schedule, a project management plan, the WBS itself, and more. These don’t just magically happen by themselves. They take work -- work by the project manager and the project team. So they need to be reflected in the WBS as tasks. Similarly, there will be meetings with stakeholders, meetings of the project team, and so forth. These, too, consume time and effort and need to be reflected as tasks in the WBS. These are just a few examples. All the work of managing a project needs to be included in the WBS as tasks.

As noted, a WBS can be either product oriented -- based on the components of the product being produced (such as, for an airplane, the fuselage, the wing, the engines, etc) -- or can be process oriented -- based on the phases of work of the project to produce the product (such as, planning, analysis, design, development, testing, integration, etc). A product-oriented WBS will typically concentrate on the nouns (fuselage, wing, hull, operating system, network), whereas a process-oriented WBS will typically concentrate on the verbs (plan, analyze, configure, design, test, etc). Both approaches are valid.

Basing the highest levels of the WBS on the SDLC is one example of the process-oriented approach.