Chapter 41: Summary - Project Management Knowledge Areas

Not all project management knowledge areas apply to all projects or project phases. Knowledge areas can interact and overlap.

All the 42 project management processes in the PMBOK are part of one of the nine project management knowledge areas:
1. Integration Management
2. Scope Management
3. Time Management
4. Cost Management
5. Quality Management
6. Human resource Management
7. Communications Management
8. Risk Management
9. Procurement Management

Project Integration Management

The processes that are part of Project Integration Management are:
1. Develop project charter
2. Develop project management plan
3. Direct and manage project execution
4. Monitor and control project work
5. Perform integrate change control
6. Close project or phase

Project Scope Management

The five processes that are part of Project Scope Management are:
1. Collect requirements
2. Define scope
3. Create WBS
4. Verify scope
5. Control scope

Project Time Management

The six processes that are part of Project Time Management are:
1. Define activities
2. Sequence activities
3. Estimate activity resources
4. Estimate activity durations
5. Develop schedule
6. Control schedule

Project Cost Management

The three processes that are part of Project Cost Management are:
1. Estimate costs
2. Determine budget
3. Control costs

Project Quality Management

The three processes that are part of Project Quality Management are
1. Plan quality
2. Perform quality assurance
3. Perform quality control

Project Human Resource Management

The four processes that are part of Project Human Resource Management are
1. Develop human resource plan
2. Acquire project team
3. Develop project team
4. Manage project team

Project Communication Management

The five processes that are part of Project Communication Management are
1. Identify stakeholders
2. Plan communications
3. Distribute information
4. Manage stakeholder expectations
5. Report performance

Project Risk Management

The six processes that are part of Project Risk Management are:
1. Plan risk management
2. Identify risks
3. Perform qualitative risk analysis
4. Perform quantitative risk analysis
5. Plan risk responses
6. Monitor and control risks

Project Procurement Management

The four processes that are part of Project Procurement Management are
1. Plan procurements
2. Conduct procurements
3. Administer procurements
4. Close procurements

Prev: Chapter 40

Next: Chapter 42

Chapter 26: Scope Management during Monitoring & Controlling the Project

Aim: To understand the following two processes related to Project Scope Management Knowledge Area in Monitoring & Controlling Phase.

• Verify Scope
• Control Scope

Verifying and Controlling Project Scope

The scope management knowledge area defines two processes in the monitoring and controlling process group. The first process, verify scope, is the formal process of accepting project deliverables. It provides a mechanism to verify that deliverables meet or exceed project requirements. The second process, control scope, is the process of managing the project’s status and any changes to the scope baseline. Let’s look at each of the processes individually.

The verify scope process provides the project manager with the formal process to classify deliverables as acceptable or unacceptable.

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

Verify Scope
Inputs	Tools & Techniques	Outputs
Project management plan Requirements documentation Requirements traceability matrix Validated deliverables	Inspection	Accepted deliverables Change requests Project document updates

One output of the verify scope process is the collection of change requests. These requests are individually addressed through the “Perform integrated change control” process and might result in approved change requests.

Exam Trivia:

Pay close attention to how the outputs of processes are used as inputs to other processes. When I took the exam, the questions were not only about identifying inputs/tools/outputs of a single process but about entities that were a common input/tool/output of multiple processes. I do understand that memorizing all these inputs, tools & outputs is difficult, but, if you understand what they are and how they are related to one another, it will be easy to crack these questions.

To know more about the Verify Scope process Click Here

The next process in the monitoring and controlling process group is the control scope process. This process monitors and controls all changes to the scope baseline to ensure the changes are being handled in a structured manner.

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

Control Scope
Inputs	Tools & Techniques	Outputs
Project management plan Work performance information Requirements documentation Requirements traceability matrix Organizational process assets	Variance analysis	Work performance measurements Organizational process assets updates Change requests Project management plan updates Project document updates

A primary component of the project management plan is the scope baseline. The scope baseline defines the project scope and its associated deliverables, and documents the acceptance parameters of the final product. This baseline helps in clarifying any details that might have been left in a to-be-determined (TBD) mode during the project initiation phase or items that require further clarification with the project sponsor or its stakeholders. The project process indicators in this process are
• The work breakdown structure (WBS)
• Work package progress reports

Exam Trivia:

Do you remember what a work breakdown structure is? A work breakdown structure (WBS) decomposes the project work into manageable chunks or work packages.

The idea behind effectively defining the WBS is to create the roadmap that defines all the activities that will be executed to accomplish the project goal.

The WBS is one of those elements that changes as time and resource utilization passes. Why? As you perform the tasks outlined in your baseline, the recorded changes accommodate any differences between the planned theory and the actual execution.
An effective WBS assists the stakeholders to understand the activities and events that help in delivering the project promise, as well as outlining internal and external resource use. The entire project execution team looks at the WBS to inquire about present, past, and future deliverables and their effectiveness.

Due to its nature and importance, the creation of the WBS should not be taken lightly. It must be considered as the one element that all project participants might want to be considered when formulating an opinion.

To know more about the Control Scope Process Click Here

Prev: Chapter 25

Next: Chapter 27

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

Points to Remember: Project Scope Management

Relationship between Product Scope & Project Scope

Product scope means the features and functions of the product or service that you and your team are building. The product scope is all about the final product—its features, components, pieces. When people talk about scoping out their products, a lot of times they’re talking about figuring out the features of the product, not the work that goes into it.

Project scope is all of the work that needs to be done to make the product. When we talk about scoping a project, we mean, figuring out all the work that needs to be done to make the product. THIS is a big part of what the project manager is concerned with and the work the team has to do.

A single product may include multiple projects and the work done in each of these projects are all part of the high level scope of the product.

Scope management means figuring out what’s OUT OF scope, not just what’s part of it

The five Scope Management processes

Each of the Scope Management processes was designed to help you avoid the kinds of scope problems that cause a lot of projects to go off track. One of the best ways to remember these processes for the exam is to understand why they’re useful, and how they solve the kinds of problems that you’ve seen on your own projects.

Collect Requirements - In this process, you find out all of the stakeholder’s needs and write them down so that you know what to build and your requirements can be measured and tracked.

Define Scope - Here’s where you write down a detailed description of the work you’ll do and what you’ll produce. When you do this right, the stakeholders are never unpredictable because you already understand their needs.

Create WBS - The work breakdown structure (or WBS) organizes all of your team’s work into work packages—or discrete pieces of work that team members do—so that you can keep the momentum of the project going from the start.

Control Scope - We already know how important it is to control changes on your project. When scope changes aren’t controlled, it leads to the most frustrating sort of project problems. Luckily, you already know about change control, and now you can use it to manage your project’s scope.

Verify Scope - Once the work is complete, you need to make sure that what you’re delivering matches what you wrote down in the scope statement. That way, the team never delivers the wrong product to the customer.

Gathering Requirements:

Three Useful Tools for Gathering Requirements:

Interviews are important ways to get your stakeholders to explain how they’ll use the product or service your project is creating. By talking to people one-on-one, you can get them to explain exactly what they need so that you can be sure that your project can meet its goals.

Focus Groups are another way to get a group of people to discuss their needs with you. By letting a group discuss the end product together, you can get them to tell you requirements that they might not have thought of by themselves.

Facilitated Workshops are more structured group conversations where a moderator leads the group through brainstorming requirements together. In facilitated workshops, misunderstandings and issues can get reconciled all at once because all of the stakeholders are working together to define the requirements

Making decisions about requirements:

A big project usually has a lot of stakeholders, and that means a lot of opinions. You’ll need to find a way of making decsions when those opinions conflict with each other. There are four major decision-making techniques you can choose from.

Unanimity means everyone agrees on the decision.

Majority means that more than half the people in the group agree on the decision.

Plurality means that the idea that gets the most votes wins.

Dictatorship is when one person makes the decision for the whole group.

The Requirements Document:

The Requirements Document needs to list all of the functional and non-functional requirements of your product. Functional requirements are most of the kinds of things that you think of right away; new features, bug fixes, new or different behavior. Non-functional requirements are sometimes called “quality attributes” because they’re things that you expect from your deliverables, but aren’t specific features. Some examples of non-functional requirements are: performance, reliablity, error handling, and ease of use.

Defining the Project Scope:

The Create WBS process is the most important process in the Scope Management knowledge area because it’s where you actually figure out all the work you’re going to do. It’s where you create the Work Breakdown Structure (or WBS), which is the main Scope Management output. Every single thing that anyone on the project team—including you—will do is written down in the WBS somewhere.

Creating the WBS:

Each of the entries in the WBS is called a work package. It’s a unit of work that you and your team use to organize the stuff you’re going to have to do to get the project done. The work package is the lowest level on a WBS; the higher levels are used to categorize the work packages. When you roll them all up into one big WBS, you get a complete picture of everything that the team will do over the course of the project.

The WBS Dictionary contains the details of every work package. It’s a separate output of the Create WBS process.

Important Points Reg. Creating the WBS Process:

1. The Create WBS process is a really important process on the PMP exam.
2. The WBS is created by decomposing large work products into work packages.
3. To finalize the WBS, control accounts are established for the work packages.
4. The WBS Dictionary is a description of each work package listed in the WBS.
5. The inputs to WBS creation are the outputs to the Define Scope and Collect Requirements processes: the Requirements Document, and the Project Scope Statement.
6. As you decompose the work, you find new information that needs to be added to the Requirements Document and the Project Scope Statement. That information is treated as a change and goes through change control. Once it’s approved, it can be added into the document, and that kicks off the planning cycle again.

Controlling Scope & Verifying Scope:

Variance Analysis:

This means comparing the data that can be collected about the work being done to the scope baseline. When there is a difference between the two, that’s variance. This tool of Control Scope is all about analyzing the difference between the baseline and the actual work to figure out if the plan needs to be corrected. If so, then you recommend a corrective action and put that recommendation through change control.

There’s no “right order” for the Control Scope and Scope Verification processes:

If you’ve got a copy of the PMBOK® Guide handy, take a look at how it presents the Scope Management processes. Did you notice how the section on the Verify Scope process comes before Control Scope? But, in real time, we may do Control Scope even before we do the Verify Scope. That’s not because the PMBOK® Guide is wrong! We could do this because there is no “right” order: Control Scope can happen at any time, because project changes can happen at any time. Verify Scope is usually the last Scope Management process that you’ll do in a project. The trick is that sometimes you’ll find a scope problem while you’re verifying the scope, and you’ll need to do Control Scope and then go back and gather new requirements,
rebuild the WBS, etc. So the Control Scope process can happen either before or after Verify Scope.

The stakeholders decide when the project is done

As you deliver the stuff in your scope statement, you need to make sure that each of the deliverables has everything in it that you listed in the scope statement. You inspect all of your deliverables versus the scope statement, the WBS, and the Scope Management Plan. If your deliverables have everything in those documents, then they should be acceptable to stakeholders. When all of the deliverables in the scope are done to their satisfaction, then you’re done. However, you need a formal acceptance to conclude that the Project is done. Formal acceptance means that you have written confirmation from all of the stakeholders that the deliverables match the requirements and the project management plan. Sometimes PMs try to close off a project just with the verbal confirmation of the key stakeholder. Though, the stakeholder may not go-back on his words and claim that you did not deliver things properly, the point here is, what if he does? What proof do you have to confirm that you have done all the work as per the scope of the project? This is where the Formal Signed Approval comes to our rescue. When a Stakeholder signs-off that he/she is happy with the deliverables, all they can do is request for some changes but not demand them because, they have provided their sign-off and that means you have delivered what you planned or promised.


Points to Remember - Other Topics:

Introduction to Projects & Project Management
Relationship Between Knowledge Areas & Process Groups
Project Integration Management
Project Time Management
Project Cost Management
Project Quality Management
Human Resource Management
Project Communication Management
Project Risk Management
Project Procurement Management
Ethics & Professional Responsibility

Important Terms & Definitions - Project Scope Planning

Let us wrap up the Project Scope Planning topic by reviewing the important terms and definitions we have learnt as part of this topic.

• Alternatives identification - A technique used to apply nonstandard approaches, such as brainstorming and lateral thinking, to perform project work.
• Baseline - A reference plan for components, such as schedule, scope, and cost, against which performance deviations are measured. The reference plan can be the original or the modified plan.
• Brainstorming - 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.
• Code of accounts - A numbering system used to uniquely identify each component of a WBS.
• Configuration management - Refers to controlling the characteristics of a product, a service, or a result of a project. It includes documenting the features of a product or a service, controlling and documenting changes to the features, and providing support for auditing the products for conformance to requirements.
• Control account - A node in the WBS that acts as a management control point where scope, schedule, and actual cost are integrated and compared to the earned value to measure the project performance.
• Decomposition - A planning technique to subdivide the project scope, including deliverables, into smaller, manageable tasks called work packages.
• Deliverable - A unique and verifiable product, a capability to provide a service, or a result that must be produced to complete a project or a process or phase of the project.
• Lateral thinking - Thinking outside the box, beyond the realm of your experience, to search for new solutions and methods, rather than only better uses of the current solutions and methods.
• Planning package - A WBS component that is below the control account that has a well-defined work content but does not yet have a detailed schedule.
• Product scope - Features and functions that characterize a product, service, or result to be delivered by the project.
• Project management plan - An approved document that describes how the project will be executed, monitored and controlled, and closed.
• Project scope - The work that must be performed (and only that work) to deliver products, services, or results with specified features that were promised by the project. The project scope draws the boundaries around the project—what is included and what is not.
• Project scope statement - A document that defines the scope of a project by stating what needs to be accomplished by the project.
• Requirement - A condition, characteristic, or capability that a specific outcome of the project must have.
• Rolling wave planning - A case of progressive elaboration in which the deliverables about which full information is available are decomposed to the lowest level, whereas the deliverables for which full information is not available are left at higher levels until the information becomes available.
• Scope baseline - The reference scope against which all the scope deviations are measured. It consists of the scope statement, the WBS document, and the WBS dictionary.
• Scope definition - The process used to develop the detailed project scope statement.
• Scope planning - The process of developing the project scope management plan.
• Subprojects - Parts of the main projects that are independent enough that each can be performed by separate project teams.
• Work breakdown structure (WBS) - A deliverable-oriented hierarchical structure that displays the decomposition of deliverables into work, which must be performed to accomplish the project objectives and create the project deliverables.
• Work package - A deliverable or a task at the lowest level of each branch of the WBS.

Previous: Summary - Project Scope Planning

Next: Introduction to Project Schedule

Summary - Project Scope Planning

In the previous chapters, we have successfully completed the Project Scope Planning section of Project Planning. Let us quickly summarize the key points we learnt in this topic.

• After a project has been initiated, the project management plan is developed to specify how the project at hand will be executed, monitored & controlled, and closed.
• The project management plan can contain subsidiary plans, such as a quality management plan, a risk management plan, a project scope management plan, and a scope baseline.
• The scope baseline consists of the project scope statement, work breakdown structure (WBS), and WBS dictionary.
• Collecting requirements is part of the scope planning, which creates requirements documentation.
• The project charter and requirements documentation are used to define the scope, which creates the project scope statement.
• The project scope statement is a document that defines the scope of a project, including the product scope, by stating what needs to be accomplished by the project.
• It includes project deliverables, product description, product acceptance criteria, assumptions and constraints, and project exclusions.
• The project scope statement and requirements documentation are input items to creating the work breakdown structure (WBS), which is a breakdown of project deliverables into manageable pieces called work packages, which in turn are used to develop the project schedule.
• The WBS is supported by another document called the WBS dictionary, which offers details for the WBS components.
• The scope statement, the WBS document, and the WBS dictionary combined constitute the scope baseline against which all change requests are evaluated.
• The WBS is the heart of project management, as it is used in managing many aspects of the project, including developing the schedule.

Previous: Before & After WBS

Next: Important Terms - Project Scope Planning

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

Chapter 24: Planning the Project

In the previous chapters, we learnt how to Initiate a Project, how to create a project charter, how to identify stakeholders and how to prepare a stakeholder management strategy.

The next big step after initiating a project is to plan for the project.

What is Project Planning?

Any Project that needs to be executed has to be planned. Any tasks that was begun without proper planning and due diligence is almost always a failure. So, as a responsible project manager you have to plan your project properly to ensure that, your baby is a success. After all, which project manager wants to spend months of his time on a failing cause? Atleast, I don’t …

What are the Phases Involved in Project Planning?

Project Planning involves 4 important phases. They are:

1. Planning the Project Scope
2. Planning the Project Resources
3. Planning the Project Schedule
4. Planning Quality & Risk Management

Each of these 4 phases is equally important and have a significant impact on the success of the project.

As Project Managers we need to put in dedicated effort to plan for each of these phases and as expected, the PMP exam covers each of these in depth.

In the forthcoming chapters, we will be starting with Project Scope Management and then move on to the other phases in Project Planning one by one.

Previous: Important Terms & Definitions

Next: Introduction to Project Planning