Regarding scope management and requirements management, both are absolutely required. I think of a balloon: Interior pressure (requirements management) keeps the balloon inflated, but exterior pressure (scope management) keeps the size of the project balloon contained. Not enough scope management and the project blows up, too much containment and the project shrinks or shrivels.

The PM is responsible for the right balance.
Posted by Jim Whitten

What I find helps to mitigate this is to have the project team document their assumptions when estimating. All assumptions are then reviewed with the customer along with the estimates. As new functionality is revealed to the project team the assumptions are then leveraged to objectively apply good change management practices.

What I’ve witnessed is that project teams get into trouble when they “feel” they should have known that the newly revealed functionality was originally intended. By documenting meaningful assumptions we are then able to be reasonable about what we understood when estimating and what we didn’t understand.

The PMBOK does not require all scope to be totally defined up front. It is this key misunderstanding that leads to much confusion.

What the PMBOK is trying to avoid is goldplating, and “end runs” — informal directives from stakeholders, managers or whomever along the lines of “wouldn’t it be nice” to a programmer “on the side” and slipping things in. Ditto for programmers putting a few “nice to haves” in on their own. Conversely, the PMBOK model is even more about not leaving anything out — overlooking odds and ends or even more important features in the rush to completion. RQM, for example.

The PMBOK is not blocking or denying additions, modifications, or deletions during the course of a project to scope or requirements. “Change request” is an output of both the Control and Verify Scope processes, for example. There is every opportunity in every project to change anything along the way. As Brian mentioned above, the real challenge lies in managing stakeholders expectations around the cost, quality, and schedule impacts of doing so.

“Skunk Works” projects are certainly allowable under PMBOK. Prototyping is defined and allowed, as one example, as a requirements gathering method. Also project phases (see definition starting on pg 18) are included in a variety of formats. This is one of the better clarifications included in the fourth edition, in my opinion.

As to your question “why, do so many project managers blame overruns or project failures on scope creep or poorly executed requirements management and change management?” the answer is, aside from the misconceptions mentioned above, based in part on how project “success” is measured. See http://enweave.blogspot.com/2009/06/defining-project-success.html for more on that subject.

Another part of the answer lies squarely on the shoulders of project managers. We don’t always do the best job of “managing” and don’t always shoulder that blame. If we “cave” to pressure from stakeholders and include a change we know will be costly without getting the resources to cover that cost, whose fault is that?

So in your question, it appears that “scope management” is really “project scope management,” or more simply, work management. And requirements management would be “product requirements management” or “product scope management.”

In short, you need to manage both. Your customer/ client/ user wants their scope and doesn’t really care about the work that you have to do. So the first thing you need to do to be effective is to change the terms of engagement:
– The definition of scope (product scope) does not end when the requirements are agreed. The development of a design document, of technical specifications, of test data, of user manuals may all result in the identification of scope changes (product scope changes).
– All scope changes (product scope changes) will be reviewed for their impact on the work that has to be done. Small changes to scope (product scope) may result in large changes to work (project scope). Small changes to scope (product scope) will almost always result in large changes to work (project scope) if they are received late in the project.
– Who pays for any additional work identified must be clearly defined at the start of the project. If the project is being done under contract, it must be defined in the contract. If the project is internal to one legal entity, then the organizational units involved should agree to a process in writing.

Implied in all this is that you need a product-oriented life cycle: a “planning phase” after the requirements are agreed borders on willful stupidity. You should use something like requirements, design, development, turnover. Go back and re-read the section in the PMBoK Guide where it says “process groups are not phases.”

Duncan

The Scope Baseline which is used to manage the scope is the “Scope Statement and its associated WBS and WBS Dictionary”. If it is not in the WBS, it is not in scope. “Verify Scope” (or Scope Verification) is “The process of formalizing the acceptance of completed project deliverables”. It is performed when the deliverables are considered complete – not a good time to disagree about or revisit what is included in the scope.

There can be a broad variety of requirements – a good project manager will help their sponsor and other stakeholders expand their imagination and develop a comprehensive list.

Requirements are sorted – in scope and out.

During the project, it is just one more aspect of progressive elaboration for scope changes to be requested.

• If these changes had not been imagined, you should look at your requirements gathering process.
• If these changes are to move requirements from out of scope to in scope, you should look at your requirements sorting process.
• If your change control process increases scope with no increase in schedule or cost, you should look at that process.
• If you have gotten a project approved but knew at that time that only future changes in scope and associated changes in schedule or budget will ensure project success, your bad.