Project Planning

Collecting Requirements and Defining Scope

Collecting requirements and defining your project’s scope are critical to planning a successful project. The PMBOK® Guide offers two related definitions for scope. Project scope includes “the work that needs to be accomplished to deliver a product, service, or result with the specified features and functions.” Because projects often create products, you may also have to define the scope of a product. Product scope includes “the features and functions that characterize a product, service, or result” (A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fourth Edition, Project Management Institute, 2008, p. 103).

Clearly defining a project’s scope is not merely good theory and common sense. Project schedules and budgets overrun when the scope is unclear and when the scope is not aligned with enterprise goals, core values, structure, strategy, staff, and systems. Studies show that projects that spend more time in planning and design have fewer overruns.

The Five Processes of Project Scope Management

The processes for collecting requirements and defining scope may be simple or complex, trivial or traumatic. In all cases, it is best done by the project team, with the sustained participation of all interested and affected parties.

Project scope management includes five processes, the first two of which are discussed on this page and the last three are discussed on the next page.

1. Collecting requirements includes the processes for identifying and documenting features and functions of the end result of the project (the product, service, or result).

2. Creating a scope statement formally documents what the project will and will not produce.

3. Creating a work breakdown structure (WBS) creates a hierarchical breakdown of activities and end products, which organizes and defines all the work to be completed in a project.

4. Verifying scope achieves formal acceptance of the project scope.

5. Controlling scope creates a change control system to manage the project scope.

Collecting Requirements

This step includes the processes for identifying and documenting the features and functions of the end result of the project (the product, service, or result). There are several methods you can use to collect project requirements. A few are listed below. To learn more about each of these, see Improving Your Project Management Skills.

Interviews
Focus Groups
Expert Judgment
Gap Analysis
Walk-Throughs
Creative Tools

SMART Requirements

One important aspect of establishing client and stakeholder expectations takes into account the difference between well-defined requirements and poorly defined ones. Although several models exist, one of them asks if the project requirements meet the SMART test, that is, whether they are Specific, Measurable, Agreed upon, Realistic, and Time/Cost limited. The SMART model is designed to minimize misinterpretation or vague assumptions.

Frequently, the project manager will be faced with the situation that a client cannot or does not fully understand what he or she wants. A similar issue exists when a client and internal stakeholders are in conflict regarding the project requirements. These situations create what are known as fuzzy requirements—those that are not specific, measurable, agreed upon, realistic, or time/cost limited.

Frequently, clients and project managers create fuzzy requirements because of misunderstandings. Clients may not understand the technology, or project teams may not understand the clients’ needs.

Creating a Scope Statement

The scope statement formally documents what the project will and will not produce. It defines your project, including objectives, specifications, exclusions, constraints, risks, and assumptions.

Objectives: Time, Cost, Scope

Projects are defined and managed within the triple constraints (or expectations) of time, cost, and scope. These objectives are commonly referred to as the project triangle.

The time constraint is defined in the project’s schedule. The ceiling on cost expenditures is the project budget. The budget itself is a scorekeeping tool that measures the anticipated rate and timing of expenditures for the labor costs, equipment, material, travel, and other items needed to meet project objectives. And, finally, the project scope includes the predefined technical and performance targets. The challenge of the project manager is to keep all sides of the project triangle balanced. If the triangle is not balanced, the project will fail along one of the three sides. For example, if you start with a “balanced” triangle and then receive a request for additional features from your customer (an increase in scope), you must make an adjustment in the time and/or cost. Otherwise, you simply won’t be able to accomplish the increased amount of work in the time and within the budget previously defined. This concept also highlights the importance of clearly and completely defining project requirements during project planning.

In prioritizing the project objectives, it is critical to recognize what drives the project. Some projects are driven by schedule. This means that a completion date is fixed and the other sides of the project triangle (cost and scope) can to some degree be negotiated. In other projects, the most important drivers are budget or scope.

The scope document should address the trade-offs among time, cost, and scope. Conventional wisdom says: “You may want it good, fast, and cheap. Pick two!” Underlying this aphorism is an intuitive grasp of simple points:

If the technical requirements of a project are fixed, then compressing the project schedule will probably increase project costs.
The more the schedule is compressed, the greater the rate of increase in cost per unit of time.
If you add requirements to the scope, then either time or cost (or both!) will increase.
If the project budget is fixed (as by legislative appropriation or a fixed-price contract), then negotiation arises on the other two sides of the project triangle (time and scope).

For any project, there are three critical data points:

The earliest finish date of the last activity
The latest allowable finish of the last activity
The least cost to accomplish all the work required

By extension, we can find a point that describes the late finish and last dollar. This point is the sponsor’s expectation that she or he will receive the final product or service on or before a given date and at a cost not to exceed some predefined amount. The area between any point on the time/cost trade-off line and the outer limits of the project is a management reserve or contingency for the project manager.

The project manager can now present the options to senior management and other stakeholders. Problems will only arise when the project budget is less than the cheapest solution or the needed delivery date is sooner than the fastest solution.

For examples and illustrations about these points, see Improving Your Project Management Skills.

Specifications

Specifications, by definition, are unique for each project. Nevertheless, they must also conform to applicable laws, standards, codes, and conventions, which may derive from sources such as the following:

*Government agencies may be international, national, state, or local agencies involved in regulating specific industries, the environment, health, safety, or transportation. Some agencies regulate standards, licensing, or zoning.
*Industry-specific professional or trade associations may develop codes, conventions, or standard practices. These associations and practices include the International Organization for Standardization (ISO), the American National Standards Institute (ANSI), Underwriters Laboratories, Inc. (UL listing), Generally Accepted Accounting Principles (GAAP), Generally Accepted Auditing Standards (GAAS), the Software Engineering Institute (SEI), and the Project Management Institute (PMI).
*Your own organization may have standards for data names and uses, numbering schemes for engineering drawings, or a visual identity program to guide the use of the company logo.
*Your customers, clients, or end users may impose their standards on your work. For example, “The contractor shall prepare and submit all engineering drawings as [name of product] files.” The standards that apply to your project should be developed early in the development of specifications. They should be articulated by subject matter experts, embedded in the scope document, and used later on to judge the quality of intermediate and final deliverables.

Exclusions

An adequate scope document defines not only what the project includes, it also establishes project exclusions. This delineation, although seldom perfect, forces stakeholders to confer openly and candidly in the early stages of a project. The project manager guides this dialogue. Its product is a scope definition with clear boundaries, diminished uncertainty, and minimal likelihood that the project manager will hear (at the end of the assignment), “I know it’s what I said, but it’s not what I want.”

Scope exclusions define items that may be closely related to the project’s goal but are not to be included in this phase, stage, or release. Exclusions may extend to piece parts, specific features and functions, materials, and performance measures. The important issue is that these exclusions be identified early, debated openly, and resolved with finality.

Constraints

Constraints are items that limit the project manager’s degree of freedom when planning, scheduling, and controlling project work. Often, these constraints are administrative, financial, or procedural in nature. The following are examples of constraints:

There is a hiring freeze for specific positions.
The project has a capital equipment ceiling of $500,000.
The team must use an executive’s brother-in-law as the architect.
A vice president must approve all travel.

Risks

Risks are uncertain events that may affect the project for better or worse. These events may be categorized in various ways, but their central theme is that one cannot predict with certainty the source, timing, impact, or significance of specific risks. Therefore, at the start of a project, it makes sense to undertake a high-level risk assessment by identifying the sources and types of uncertainty.

The initial assessment of risks to the project involves three steps:

Identify the risks likely to impede project progress and success.
Rank each risk in terms of the likelihood of occurrence and the impact on the project if the risk occurs.
Develop an initial list of responses for the risk that have unacceptable outcomes.

Assumptions

Assumptions are made to fill in gaps of credible knowledge, to simplify complex realities, and to get others to react. One way to categorize assumptions is to group them under one of four headings:

Technical and scientific assumptions routinely deal with hardware, software, or related configuration issues. We can postulate change or stability. In designing an experiment, we might assume that ten tests will be required or that a certain number of patients must be enrolled to achieve some level of confidence in results.
Organizational and administrative assumptions typically deal with roles and responsibilities, issues of outsourcing versus internal development, or make-or-buy decisions. By extension, they may address applicable standards for documentation or the tenure of project staff at the end of the project.
Resource and asset availability assumptions address issues regarding whether adequate numbers of people, materials, supplies, space, and equipment are available to meet project requirements. This set of assumptions requires the project manager to revisit some of the organizational assumptions noted above.
Macro-level assumptions are those that are so profound or pervasive that project managers cannot negotiate them in any meaningful way. We could include here issues of currency fluctuations, exchange rates, public policy, population migrations, and related demographic trends.

To learn more about the concepts discussed on this page, see Improving Your Project Management Skills.

Recommended Books

Improving Your Project Management Skills.

American Management Association.

Buy at Amazon

Project Management Center of Excellence