Chapter 11: Project Scope Management as part of Project Planning

Aim: To understand the Processes those are part of the Project Scope Management area. They are:
• Collect Requirements
• Define Scope &
• Create Work Breakdown Structure

Scope management is the set of processes that ensures that the requirements of the customer are captured in a specification of work that ensures the delivery of the project’s deliverables, that all the project work is done, and that only the work required to complete the project is done. In other words, scope management makes sure that the project is completed without expending any unnecessary effort.

The collect requirements process seeks to use multiple tools and techniques to collect all of the project requirements from all of the stakeholders. This process attempts to leave no stone unturned and results in a complete list of project requirements. When properly performed, the collect requirements process dramatically reduces surprises as the project progresses toward completion.

The table below shows the inputs, tools and techniques, and outputs for the collect requirements process.

Collect Requirements
Inputs	Tools & Techniques	Outputs
Project charter Stakeholder Register	Interviews Focus groups Facilitated workshops Group creativity techniques Group decision-making techniques Questionnaires and surveys Observations Prototypes	Requirements documentation Requirements management plan Requirements traceability matrix

You can learn more about the Collect Requirements Process by Clicking Here

The next process, define scope, is the process that clearly states what the project will and will not accomplish. The supporting documents are reviewed to ensure the project will satisfy the stated goals and the resulting scope should state the stakeholders’ needs and clearly communicate the expectations for the performance of the project.

The table below shows the inputs, tools and techniques, and outputs for the scope planning process.

Define Project Scope
Inputs	Tools & Techniques	Outputs
Project charter Requirements documentation Organizational process assets	Expert judgment Product analysis Alternatives identification Facilitated workshops	Project scope statement Project document updates

You cal learn more about the Define Project Scope process by Clicking Here

Work Breakdown Structure

Many inexperienced project managers move too quickly from the scope statement to the activity sequencing processes. This practice is a mistake and often leads to activity omissions and inaccurate plans. PMI stresses the importance of creating a work breakdown structure (WBS) before moving to activity management processes.
The WBS provides the project manager and project team with the opportunity to decompose the high-level scope statement into much smaller, more manageable units of work, called work packages. The resulting WBS should provide a complete list of all work packages required to complete the project (and most importantly nothing more).

The table below shows the inputs, tools and techniques, and outputs for the create WBS process.

Create WBS
Inputs	Tools & Techniques	Outputs
Project charter Requirements documentation Organizational process assets	Decomposition	WBS WBS dictionary Scope Baseline Project document updates

In creating the WBS, the project team repeatedly decomposes the work of the project into smaller and smaller units of work, resulting in a collection of small work packages. The process continues until the resulting work packages are simple enough to reliably estimate duration and required resources. Don’t go overboard, though. When you have work packages that are manageable and represent a single work effort, stop the process. Each project is different, so this process results in different levels of detail for each project.

Exam Watch:
The term “work package” refers to an individual project activity. The work package is the lowest level WBS component. According to the PMBOK, “A work package can be individually scheduled, cost estimated, monitored, and controlled.”

The last main feature of the WBS is that it is organized in a hierarchical fashion. The highest level is the project. The children that represent project phases, divisions, or main deliverables are listed under the project. Each child process or task is divided into further levels of detail until the lowest level, the work package, is reached. Below is a sample WBS with multiple levels.

In addition to the WBS itself, another output of the create WBS process is the WBS dictionary. The WBS dictionary is a document that supports the WBS by providing detailed information for each work package. The WBS dictionary can contain many types of information, including
• Work package name or identifier
• Accounting code identifier
• Description of work
• Technical specifications
• Quality requirements
• Owner or responsible party assignment
• Required resources
• List of schedule milestones
• Associated schedule activities
• Cost estimates
• Acceptance criteria
• Contract information

You can learn more about the Create WBS process by Clicking Here

Prev: Chapter 10

Next: Chapter 12

Chapter 29: Requirements Collection Process

As explained in the previous chapter, collecting requirements for a project is by far the most important activity of any project. Remember the restaurant, order collection activity? Would you like to eat what the restaurant wants you to eat or what you want?

In this chapter, we are going to take a look at how the requirement collection activity happens.

So, lets get started!!!

Collecting Requirements:

You collect requirements by using the Collect Requirements process as shown in the picture below

As you can see, the Project Charter and the Stakeholder Register are the inputs to the Requirements Collection process.

With these input items at your disposal, you use some tools and techniques to collect the requirements.

Tools and Techniques for Collecting Requirements

You collect the needed information about the requirements by using various techniques, such as observations, interviews, questionnaires and surveys, focus groups, facilitated workshops, group creativity and decision making techniques, and prototypes. Let us take a detailed look at these tools & techniques. Even though, you might be aware of these things, there is no harm in
revising them again...

Observations

Observation is the technique in which the requirements about a product or process are gathered by directly observing the user who is going to use the product or perform the process.

Interviews, questionnaires, and surveys

An interview is typically performed by asking predetermined and on the spot questions and recording the responses of the users/stakeholders. Depending on the situation, interviews may take several forms, such as one on one, multiple interviewees, or multiple interviewers. For example, by interviewing subject matter experts and individuals who ran similar projects before, you may identify and define some features and functions of the project deliverables.
When you want to cover a large number of respondents quickly, questionnaires and surveys will be more appropriate. These are based on written sets of questions. It is always easier to have those people answer the questions in one shot than having to meet them all one by one and collecting their response.

Focus groups

A focus group is a set of prequalified stakeholders and subject matter experts that are brought together with the purpose of learning about their opinions, expectations, and attitudes about a product, service, or result that will be the output of the project. Generally speaking, a moderator facilitates the interactive discussion to make this experience more conversational than one-on-one interviews.

Facilitated workshops

A facilitated workshop is a session that brings together the cross-functional stakeholders to focus on defining product requirements. It generally proves to be an effective technique for quickly defining cross-functional requirements and reconciling differences among the stakeholders regarding the requirements. These workshops also help in developing trust and improving communication among the stakeholders and therefore fostering relationships that will help the project to succeed.

Group creativity techniques

These are group activities organized to identify project & product requirements. Some examples are:

• Affinity diagram - In this technique, a large number of ideas are classified into different groups by using some criteria. This facilitates an effective and efficient review and analysis.
• Brainstorming - This is a creative technique generally used in a group environment to gather ideas as candidates for a solution to a problem or an issue without any immediate evaluation of these ideas. The evaluation and analysis of these ideas happens later. This is one of the most widely used techniques where you let everyone come up with creative ideas and then consolidate/analyze them to choose the best suggestions. There are two specific kinds of brainstorming, which are:
     o Idea/mind mapping - This is an individual brainstorming technique in which a multitude of ideas are mapped around a central or key concept in order to expose commonalities and differences among ideas and generate new consolidated ideas. Mapping also helps in classifying ideas into groups by discovering relationships among them. In addition to project management, this technique is also used in other areas, such as personal, family, and education. It helps in summarizing, clarifying, and revising ideas.
     o Nominal group technique - This is the brainstorming technique with voting. The voting process is used to rank the ideas generated by brainstorming for further brainstorming or for prioritization.
• Delphi technique - This refers to an information-gathering technique used for experts to reach a consensus while sharing their ideas and preferences anonymously.
Group decision-making techniques
Group decision making is, in general, a process used to collectively assess and evaluate multiple alternatives in terms of expected outcomes. The decisions usually result in taking specific actions. This general technique can also be used to identify/generate, classify, and prioritize project requirements, including the product requirements. To reach a group decision, multiple methods are available. Some are:
• Dictatorship - One person has the authority to make the decision. While this expedites the decision making, it may not be the most effective decision-making method. This is usually because, people don't like to be told what needs to be done in a one way traffic kind of environment
• Unanimity - This is opposite of dictatorship. A decision is accepted only if everyone agrees.
• Majority - A decision must be supported by more than 50 percent of the members of the group. Like a usual election
• Plurality - The alternative supported by largest number of members wins even if this number does not make a majority. This situation arises when there are more than two alternatives. Plurality with two alternatives is simply a majority method.

Prototypes

A prototype is a working model of a product put together without developing the actual product. Organizations usually make prototypes for developing proof of concept. Prototypes can also be used to collect requirements by experimenting with the prototype and by letting stakeholders experiment with it and offer feedback. A prototype is more tangible than the abstract idea of a product. Prototypes can be improved and modified based on feedback from the stakeholders. In this way, prototypes support the progressive elaboration process of developing requirements.

Trivia:
Prototyping is a very effective way of getting new projects. Large IT organizations who serve clients, usually have senior members of their organizations (working for that client) to come up with possible enhancements to their existing IT system. These ideas are then made into small working prototypes that can be explained easily to the customer. Once the customer likes the prototype, he/she can be convinced to grant the budget required to take up this initiative as a full fledged project. In my personal experience, this method has a very good success or hit rate.

You use one or more of these techniques to generate the output of the Collect Requirements process.

Output of Collecting Requirements

During this process of collecting the requirements, you will produce two documents:

• The stakeholder requirements document and
• The requirements management plan.

Requirements documentation

Also called the stakeholder requirements document, this document consists of a list of requirements and any necessary detail for each item in the list. The details of the requirements and the format of the document depend on the project and the rules within the performing organization. CMMI level 4 or higher organizations usually have predefined formats using which they prepare such documents.

Following are some essential elements of the requirements document:

• Sources of requirements - This describes the overall project outcome to which the requirements apply and the purpose of the project, such as the opportunity being seized or the business problem being solved.
• Types of requirements - For effective management, you can organize the requirements into different categories using some criteria. For example, all requirements can be broadly organized into two categories: functional requirements, referring to the functionality of the project outcome, and nonfunctional requirements, such as compliance, compatibility, and support. Furthermore, these broad categories can be subdivided into more specific types, such as the following:
     o Quality requirements, such as not more than three bugs per software module.
     o Support and training requirements, such as that the product will be released with a manual.
     o Requirements that are based on assumptions and requirements that lead to constraints, for example, phase one of the project must be completed before a specific date.
• Impacts of the requirements - This element describes the impact of requirements on the project and on entities external to the project, such as different groups in the organization.

Requirements management plan

This plan documents how the requirements will be managed throughout the project life, which includes how they will be documented and analyzed.

The requirements management plan includes the following elements:

• Prioritization - The process and criteria to prioritize the requirements.
• Configuration management - How the changes to the requirements will be processed: initiated, analyzed, tracked, and reported.
• Reporting - How, by whom, and to whom the activities related to the requirements will be reported.
• Traceability - What the traceability structure of the requirements will be, for example, which attributes of a requirement will be captured on the traceability matrix.

Requirements traceability matrix

As the name suggests, the requirements traceability matrix is a table that traces each requirement back to its origin, such as product or business objective, and tracks its progress throughout the project life. Linking a requirement to the business objective underlines its value. Tracking the requirement throughout the lifecycle of the project ensures that it will be delivered before the project is completed. So, this table becomes a very useful tool to remind the team how important these requirements are, when they are going to be implemented, and how they are progressing in implementing them.

The requirements traceability matrix includes the following:

• Requirements linked to the origin of the project, such as the opportunity or business need
• Requirements linked to the project objectives and deliverables
• Requirements linked to the project scope and the product scope
• Requirements linked to the product design, development, and testing
• High-level requirements linked to their details
• The attributes linked to a requirement

Trivia:
The Traceability Matrix is a valuable tool at the end of the project to validate if all the requirements have been captured in the end product. Every single entry in the traceability matrix must have been addressed by the product in order for it to be a success/completed project.

Previous: Collecting Requirements for Projects

Next: Defining the Project Scope

Chapter 28: Collecting Requirements for the Project

In the previous chapter, we saw the importance of scope management and how a good project manager would manage the scope of his project. In this chapter, we are going to take a look at Gathering Requirements for the Project…

So, lets get started!!!

What is Gathering Requirements?

Gathering Requirements is the phase in the project where we begin by identifying what the user or the customer (the person who is going to use the project/product) wants. Without a clear cut idea of what the user wants, we cannot possibly give it to him.

A requirement is a condition, characteristics, or a capability that a specific outcome of the project must have.

Requirements may come from different sources, such as from standards, specifications, and contracts. Stakeholder expectations and needs often materialize into requirements as well.

A Real Life Example:

Lets say, you walk into a restaurant with your spouse. Usually the Restaurant Floor Supervisor would walk up to your table and greet you first and then ask you for the order. You will tell him all your favorite dishes and he will go place the order with the kitchen staff. If no one from the restaurant comes up to ask you what you want, can they give you what you like to eat? Unless the floor supervisor captures your order in a notepad correctly (without missing your favorite dishes) you will not leave the restaurant satisfied.

The part where the floor supervisor in the restaurant notes down all your dish orders is equivalent to the Requirements Gathering Phase of a Project.

Unless, the requirements are gathered correctly, the outcome will not be nice and the customer is going to be unhappy.

Trivia:
Generally speaking, project requirements should include the product requirements. However, you may find that, many organizations distinguish between project requirements and product requirements. The project requirements include strictly project-related requirements, such as schedule and delivery requirements, business-related requirements, and other project management requirements, whereas the product requirements include the product-related requirements, such as requirements related to performance, security, and defects.

Requirements Planning

In order to capture requirements correctly and accurately, we need to plan the whole activity. You, as the project manager need to do some requirements planning, which includes:

• Defining and documenting the project requirements
• Defining and documenting the product requirements
• Developing a plan to manage the requirements; the requirements management plan

You do all this in order to determine and fulfill stakeholder expectations and needs. In other words, get the order correctly so that the customer will eat what he wants and leave happily.

Trivia:
How effective you are in capturing requirements will directly impact how effectively you will be able to meet the stakeholder requirements/expectations. Hence it is imperative that proper requirements’ gathering is required for any successful project.

In the next chapter, we will take a look the Requirements Collection Process.

Previous: Managing Scope

Next: Requirements Collection Process

Chapter 27: Managing Scope

In the previous chapter, we saw how important it is to create the Project Management Plan and also about how to create it. Let us now get into the Scope Management part of our Project Planning phase.

What is Scope?

The scope of a project consists of the project scope and the product scope. The project scope is defined as the work that must be performed to deliver the required products, services, or results with the specified functions and features. The product scope is the set of functions and features that characterize a product, service, or result to be delivered by the current project.
It is about both what is included in the project and what is not. In other words, scoping a project means drawing boundaries around it, so that everyone knows what will be done and what will not be done. The importance of managing the project scope cannot be overemphasized because it has a profound impact on the overall success of the project.

Trivia:
Project scope is not the same thing as the product scope. Project scope is the work required to deliver the product scope.

Is Scope Management Important?

If you feel the scope management is not important, imagine this:

Let’s say you started a project to deliver an online banking website for ABC Bank and are 6 months into development. The go live date is in 12 weeks and the customer wants to include credit card information in the website. This was not part of the initial estimates & scope.
Unfortunately, your project manager accepted this because he wanted to please the customer.
Now think what will happen to you and your team mates? You all will be neck deep in unexpected work and the next 12 weeks will be most miserable work days of your life and that is only if you manage to deliver the project to the customer. If you don't, then its only going to get worse…
If your project manager had put his foot down and said, the credit card details were not part of the initial scope & estimate and a change of this magnitude cannot be taken up in such a short notice of 12 weeks, imagine the scenario…

Now you get the idea of why scope management is important?

What is Project Scope Management

The major goal of scope management is to ensure that the required work and only the required work is included and performed in the project.

Just go back to the previous paragraph and read the example. If the project manager had a scope management document that outlined the list of tasks that will be completed as part of the project, he could use that to substantiate his argument that, such a large chunk of work cannot be taken up this late in the project execution.

The Project Scope Management will do the following:

1. Collect requirements - Define the project and product requirements and develop a plan to manage those requirements. This will help clarify what needs to be done.
2. Define scope - Develop a detailed description of the project and the product that will determine what needs to be done.
3. Create work breakdown structure (WBS) - Break down the scope into concrete, manageable components.
4. Verify scope - Formalize the acceptance of the completed project deliverables. Identify how you will verify that the project scope has been executed as planned.
5. Control scope - Determine how to monitor the status of the project and product scope and monitor and control changes to the scope.

Let us take a picture to understand this better.

Note: The above picture is a high level view. Each stage may involve an in depth analysis by the Project Manager to capture accurate information.

Let us now take a look at which process group each of these activities belong to and what the output of these activities would be.

Scope Management Process	Process Group	Output
Collect Requirements	Planning	Requirement management plan and other requirement documents
Define Scope	Planning	Project scope statement
Create WBS	Planning	WBS and scope baseline
Verify Scope	Monitoring and controlling	Acceptance of deliverables and change requests
Control Scope	Monitoring and controlling	Work performance measurements

Developing the Project Scope Management Plan

Before starting to perform the five scope management processes, you develop the scope management plan. This work is recommended to be part of the effort of developing the project management plan. This plan will work as a guide for handling the following:

• How can you define the scope? To answer this question, the scope management plan includes the following:
      o A process to prepare a detailed project scope statement based on the preliminary project scope statement.
      o A process that will enable the creation of the work breakdown structure (WBS) from the detailed project scope statement and will establish how the WBS will be maintained and approved.
• How can you verify the scope? The scope management plan answers this question by including a process that describes how the formal verification and acceptance of the completed project deliverables will be obtained.
• How can you control the scope? The scope management plan answers this question by including a process that specifies how the requests for changes to the detailed project scope statement (which we also refer to as the scope statement) will be processed.

Whether the project scope management plan is informal and high-level (without too much detail) or formal and detailed depends upon the size, complexity, and needs of the project.

The project scope management plan becomes part of the project management plan.

So, the project scope planning specifies how to define, verify, and control the project. Before you can actually define the scope, though, you need to have a very crucial item in place: stakeholder requirements.

Previous: Developing Project Management Plan

Next: Collecting Requirements