For more than 50 years, Auerbach Publications has been printing cutting-edge books on all topics IT.

Read archived articles or become a new subscriber to IT Today, a free newsletter.

This free newsetter offers strategies and insight to managers and hackers alike. Become a new subscriber today.


Partners




Contact

Interested in submitting an article? Want to comment about an article?

Contact John Wyzalek editor of IT Performance Improvement.

 

The Scope of Project Scope Management

Jamal Moustafaev

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 aware—at least at a high level—of 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

This article is an excerpt from:

Incomplete or missed requirements, omissions, ambiguous product features, lack of user involvement, unrealistic customer expectations, and the proverbial scope creep can result in cost overruns, missed deadlines, poor product quality, and can very well ruin a project. Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects describes how to elicit, document, and manage requirements to control project scope creep. It also explains how to manage project stakeholders to minimize the risk of an ever-growing list of user requirements.

The book begins by discussing how to collect project requirements and define the project scope. Next, it considers the creation of work breakdown structures and examines the verification and control of the scope. Most of the book is dedicated to explaining how to collect requirements and how to define product and project scope inasmuch as they represent the bulk of the project scope management work undertaken on any project regardless of the industry or the nature of the work involved.

The book maintains a focus on practical and sensible tools and techniques rather than academic theories. It examines five different projects and traces their development from a project scope management perspective—from project initiation to the end of the execution and control phases. The types of projects considered include CRM system implementation, mobile number portability, port upgrade, energy-efficient house design, and airport check-in kiosk software.

After reading this book, you will learn how to create project charters, high-level scope, detailed requirements specifications, requirements management plans, traceability matrices, and a work breakdown structure for the projects covered.

About the Author

Jamal Moustafaev, MBA, PMP, president and founder of Thinktank Consulting, is an internationally acclaimed expert in the areas of project/portfolio management, project scoping, process improvement, and corporate training. He has completed projects for private sector companies and government organizations in the United States, Canada, Europe, Asia, and the Middle East, including the US Department of Defense (USA), Siemens (Germany), Petronas Oil (Malaysia), and TeliaSonera (Sweden), to name a few. Moustafaev is a certified Project Management Professional (PMPR). He holds an MBA in Finance and a BBA (Finance and Management Science) from Simon Fraser University