Scope Management, as defined by the Fourth Edition of the PMBOK®, is to primarily ensure that the project includes all of the work required, and only the work required, to complete the project successfully. This seems to be pretty straight forward, and easy to understand. We want to make sure that we have allocated resources (people, products, services) to complete the work that is desired, and only that work. No ‘government or skunk works’ initiatives should be included. In short, we want to put a fence around what is authorized to be worked on, and make sure that it all stays within the fence, and nothing else sneaks in under the fence.
Then why, do so many project managers blame overruns or project failures on scope creep or poorly executed requirements management and change management?
While change management is an important factor in this discussion, we will leave it for another time – other than to acknowledge that if you do not have an effective and supported Project Change Management Process, you are in for a rocky ride – regardless of how good your Scope Management Plan is. The PMBOK® goes on to define a fairly straight forward [1]Scope Management Process, as outlined below.
- Collect the Requirements
- Define the Scope
- Create WBS
- Verify Scope
- Control Scope
However, experience within the IT sector, based upon direct experience shows that many times, Scope Management and Requirements Management are treated as two separate items. For many years while working in the IT Delivery Department for a business unit of a large bank, we battled back and forth time and again with the business unit on methodology, process, deliverables and what they truly needed. Alternately, we were also required to adhere to the needs of our IT Governance body that expected us to follow the methodology and processes that had been approved and implemented for our use. One of our common battle grounds was on Scope Management.
Our methodology and process were based closely on the PMBOK® Guide, and tailored to the overall company needs and desires. By following our approved process, it generally took between 3-4 weeks to complete and get approved a scope document that ranged in size between 10 and 25 pages long, dependent upon the size and complexity of the project. We would then go into planning, whereby we would take the approved scope document, and then start work on the Requirements Document. In general, the Scope Document was never looked at – or used again on the project once ‘Requirements’ was underway. It was ‘poor execution’ that was repeated on project after project for many years.
A group of our project managers were tired of being the whipping boy on process overload, so we proposed a modification to our ‘Business/IT Processes’ in this area. We defined a ‘Scope Document’ and management process that defined what was to be included in the project (within scope); what was specifically excluded from the project (out of scope); the primary Business Reason that was being addressed; and the projected costs and timeline that defined the major phases and milestones of the project (Planning, Design, Execution/Test, Implementation). The other requirement that was put into place was that the scope document, could not be longer than two pages – maximum. Any document that was submitted to the PMO office for consideration was returned if longer than two pages. What we accomplished was to define:
A Practical Approach to Scope Management
The end result of our actions resulted in our ability to define, submit, complete and gain formal approval for all our project work in a timely and efficient manner. Since we still needed to perform ‘Requirements Management’ during our planning phase, it enabled us to save many hours and considerable effort, just to get the project formally approved and start building the project team. Our new process was approved and signed off on by the Business Unit, our Departmental IT Management and the Corporate PMO as meeting governance standards.
We had many, many small to medium sized projects that needed to be approved quickly and efficiently to not only satisfy our methodology, but to also help satisfy SOX and other Banking/Regulatory requirements in the approval process. Before this process was put into place, we averaged spending 2-3 weeks and 150-200 man hours getting each project scope document approved. With the new Scope Management process, we averaged 2-3 days, and less than 35 man hours of effort to complete and gain approval for a project. As a side benefit, we no longer had the knock down arguments on process and methodology with our business unit. This of course, made us both much happier.
As defined within the PMBOK®, we are given the ability to decide what type of documentation and process (details) that are used. If your group or organization is struggling with this type of situation, don’t be afraid to look outside the box for a good solution. We not only had an approved process, but we alleviated an area that had been a real sore spot with our business sponsor. That, and everyone in our IT group that worked on projects, had a new belief that process – when used properly, can be your friend.
[1] ©Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fourth Edition
{ 9 comments… read them below or add one }
Personal experience has shown that despite any organization’s best efforts to define what was and wasn’t in scope, it mattered little once the Relationship Manager (RM) was face-to-face with the Client. The transition and transformation from in-house to outsourced IT had been oversold and was, in the Client’s eyes, being under-delivered. Regardless of the RM’s understanding of program/project management and what had been agreed upon between the “outsourcer” and the Client in the scope documents, it came down to the RM folding on delivery, including new requirements, every time the Client and RM met. In circumstances like these, program/project managers are akin to a good fighter in the ring, always bobbing and weaving doing their best to avoid the next punch (aka, damage control). The RM’s inability to “back-up” the scope document (and the PPMs/PMs and clients’ who wrote it) in the presence of the Client with words and actions cannot save any project from cost and time overruns and jeopardized quality. Your scope document and all your efforts to avoid “gold plating” (PMBOK’ism) the program/project will be for naught if your Project Sponsor (in this case it should have been the RM) and your Client can’t stop the ebb and flow of changing requirements. Seen from the Client’s viewpoint, there’s no reason to “concede” anything to the Scope when you stand to get something for nothing. This logic then “piggybacks” onto the requirements definitions and on the circle goes. To summarize: If neither service provider nor client has any “skin” in the game (program/project), don’t expect anyone to say, “Ouch!”… until litigation begins.
First a bit of PMI speak clarification:
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.
Most of the projects that I have been involved with included “hidden agendas” that we were not to discuss, but were also part of the sponsor’s understanding of the scope of work. For example, on one project, the item on the agenda was to “wow” the client so the company could get the next project. On this particular project the budget was thin, but we were successful, and were awarded the next project. Had the project been successful in all other aspects, the sponsor would have considered the project unsuccessful. No additional resources were given to ensure that this factor was covered, we simply had to deliver an award to the next project in addition to the current one.
Not all organizations have a straight forward process to track changes and scope, and PM’s are left to their own tools to assure these aren’t the cause of a derailment.
PMO’s, as process and procedure owners should take statements from PM’s (like the ones you have shared above) and dig deeper into the root causes to refine the process and procedures and ensure that the costly lesson is not ignored. When these lessons are ignored, everyone is a looser.
There is a HUGE difference between the work and the scope. In the PMBoK Guide (at least in the original; I don’t know what has changed in the last 2 versions), we used the terms “project scope” to refer to work and “product scope” to refer to what I now simply call “scope.”
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
There is a common misconception at work here. Neither PMI nor the “real world” require everything to be known initially and only the work known initially to be completed within the project. In PMBOK, follow the arrows and dotted lines and you find that change is a part of the scope processes. It is certainly the case in the real world ;~) and PMBOK mirrors that reality. What the PMBOK does require is all scope be known (pubic, open, transparent) and managed including changes.
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?
I would like to add also the consideration of previous experience in a similar project when it is allowed. The change control procedure must be highlighted in the contract and shared later on in the initial phase together with the project team in order to avoid any misunderstanding about the project boundary definition and eventual change during the work in progress.
At the end a good negotiation of the contract especially in the government business in most of the case could help in the requirement definition perspective.
What I have seen is that when requirements are “baselined” it is often at a high level of detail that does not fully support the ability to execute the project. As the customer’s understanding of their needs matures along with the project team’s understanding, functionality is revealed that the customer implies was originally intended although not fully detailed. Of course, the project team has not estimated this work because they did not understand this newly revealed functionality … and the scope gets “squishy.”
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.
In my experience, the devil is in the details. A typical project starts with a high-level scope statement and as the project moves forward it drills down into the detaiIed requirements. If the scope definition is sufficiently vague (which is often the case as it is one of the first documents produced, when not much may be known about the project) it’s easy to miss important and costly details which must be included to meet the agreed-upon scope. As an extreme example, say your scope simply says to build a 5-room house, and you base your estimate on the defined square footage. Okay, but is it to have vinyl siding or brick? One bathroom or two? If the customer wants to add a 6th room, that’s clearly a scope change, but are these other things scope changes or just choices? Drilling down to the detailed requirements, scope change or not, can have a profound impact on the budget and timeline.
There can be many sources that drive scope creep.
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