The Scope of Project Scope Management
The field of project scope management seems to be one of the most neglected domains in project management. Until recently, most of the project management textbooks stated something to the effort of, "Once the project manager gets the product scope definition from the technical experts, she can embark on the creation of the project work breakdown structure (WBS) with the assistance of her team."
How exactly this product scope definition is arrived at and what steps should be undertaken to get from the point when the customer walks into the room and states that she needs a custom desk for her office to the point in time where both the blueprints and the bill of materials for said desk are finalized remained unclear.
Interestingly enough, the information technology and software development industries do have a framework called business analysis, or systems analysis, or requirements engineering that was specifically designed to fill this void in the field of project management. In the IT field, the tasks of gathering business requirements and breaking them down into high-level features and functional and nonfunctional requirements typically fall under the responsibility of the business analysts.
In architecture, engineering, and product development, the tasks of eliciting product scope fell into the laps of engineers, architects, and designers who later supplied the project manager with the product scope so that he could build a work breakdown structure, network diagram, and the like.
Key Problems with Scope
An observation of project management practices in various industries confirms that in many instances scope management in general and scope definition in particular tend to be viewed as exclusive technical areas, which leads to several very legitimate questions frequently asked by many of my colleagues:
- If the project manager is to lead the project, should he also lead the product definition stage?
- If scope size and complexity have a direct impact on project timing and budget, shouldn't the project manager be awareat least at a high levelof how the technical team arrived at the current scope in order to be able to make trade-off decisions?
- Our engineers (designers, developers, architects, etc.) are very good at design but not very skilled at interacting with customers and extracting the requirements from them. What should we do in this scenario?
Finally, and most importantly, what about enterprise or multidisciplinary projects? With the size and complexity of projects growing, it is not unusual now that the project scope encompasses the entire organization. Let us look at a couple of examples from different industries.
Port Upgrade: Container Terminal Construction Project
The first one is, as it was initially labeled by the senior executives, the "construction of the new container terminal" project. The logic at the top of the port authority literally was, "Because this is a construction project, there is no need to worry on our end; we will just outsource the construction part to the contractor."
But a very quick analysis discovered the following situation (see Figure 1). The organization consisted of multiple departments, including real estate, public relations, legal, marketing, planning, engineering, IT, logistics, and security divisions, to name just a few. It turned out that each one of these departments had its own portion to contribute to the overall larger scope of the project. In other words, the real estate department had to purchase the land required for construction. They had to perform this task in close collaboration with the legal department that made sure no local laws or bylaws were broken. The PR department was responsible for working with federal, state, and municipal governments to communicate the plans and the progress of the project and to ensure that their interests were considered in the project.
Figure 1. Port Upgrade Project
Furthermore, the marketing department representatives had to start their "cheerleading" dances for their Asian partners in order to promote the yet-to-be-built port facility. In the meantime, the planning division had to oversee the design of the new facility and pass it over to the engineering department, which would be responsible for finding the contractor and monitoring him during the execution stage. At some later point, the IT specialists were supposed to set up the entire network in the new building including hardware and software. And finally, the security people had to ensure that the new facility conformed to the federal government's security standards.
So, here is the key question: Is this really just a construction project? And inasmuch as it obviously is not, what techniques, standards, and methodologies should be used in capturing the scope? Should the project manager utilize the engineering or architectural standards? But they are not very suitable for documenting the IT or marketing requirements. Or should each department write its own separate scope document? But in that case is there a chance of dependencies between different scope elements that will most likely be overlooked if the requirements are captured in different documents and are written in different "languages"? For example, is it possible (let us consider the most primitive example for simplicity's sake) that the server room designed by the architects will be of inadequate size or design for the needs of the information technology people?
Wireless Company: Mobile Number Portability Project
This story involves a wireless company in Europe that enjoyed a very dominant position on the local market (more than 53%) with three major players in the country. At one point the country's ministry of communications decided to enact legislation similar to that already implemented in many Western countries, namely the Mobile Number Portability Act. This law would enable wireless customers to switch their cellular providers freely while keeping both their phone numbers and the prefixes.
Initially the senior management of the mobile company viewed this project as a small endeavor to be undertaken by their IT department and a group of network engineers. It was assumed that there may be a need for an additional server or two and some tinkering with the call-processing software. However, a quick guided brainstorming of the project scope produced a multitude of questions. Here are some of them:
- With this new law, switching mobile providers will become very easy. Should our marketing team prepare for the "marketing war" that would most surely start as soon as this law goes into effect?
- There probably will be a significant increase in the number of calls to the customer service centers. Should we increase the number of attendants in these centers?
- Will there be any impacts on the value-added services our company provides?
- Should we create new curriculum and conduct training for sales, marketing, and call-center people, to name just a few departments?
- Should our legal agreements with customers be revised?
Figure 2. Mobile Number Portability Project
The scope of the project suddenly "exploded" (see Figure 2) with the appreciation of the fact that, from that point on, the entire company had to be involved in the project. Like the port upgrade project, this project, upon close analysis, turned out to include almost every department of the organization that initiated it, which has major implications for project scope management.
Read more IT Performance Improvement
Certain names and logos on this page and others may constitute trademarks, servicemarks, or tradenames of
Taylor & Francis LLC. Copyright © 20082015 Taylor & Francis LLC. All rights reserved.