Work Breakdown Structure (WBS)

Once you are done with the Define Scope process, the next process in your journey of Scope Management knowledge area is the Create WBS process. The best way to understand this process is to start from the point of understanding the WBS.

Now if you are a newbie in Project Management, one of the many weird terms you need to get yourself acquainted to is the WBS. WBS stands for Work Breakdown Structure and is basically a way to organize the project team's work into manageable parts.

Breaking up the definition of WBS into two parts can help interpret it much better,
- WBS is 'deliverable' oriented (not 'activity' oriented)
- WBS is a hierarchical decomposition of the work

An example of a WBS is below,

Check more articles on Scope Management

Cross Cutting Skills - Exam Content Outline

Avoid the 7 Deadly Sins of PMP

1. Treating PMBOK as the only source of truth

2. Considering Professional experience above PMI perspective

3. Exam anxiety

4. Over thinking and over analyzing

5. Retaking the exam

6. Not creating a PMP Brain Dump

7. Not making use of the 4 hours of exam







Requirements Document or Project Scope Statement | Where do these items go?

Gig Economy - Success in Disruptive Economy

Is it mandatory to perform Alternatives Generation if there's only one way of doing something?

Proficient, Moderately Proficient, Below Proficient | Understanding your PMP Exam Result

What should you know about Expert Judgment?

Have you ever had a person in your project team that understood every single technical detail of the project end-to-end? These are experts. Don't you wish you could have an expert on all your projects? But aren't experts always busy working on the most important projects? To solve this, there is one name in the list of "Tools and Techniques" that you will see over and over again - Expert Judgment

Due to its multiple appearances throughout the Project Management landscape and its sheer usefulness, Expert Judgment is often recommended as one of the best tools and techniques. This relies on the very idea that experts are an asset of an organization and should be leveraged in the most effective way possible. Project teams typically need the help of experts during several planning processes. Planning is one of the most important part of Project Management and having an unbiased and expert opinion during planning can help avoid massive goof-ups later.

Consider a relatively new project manager working on the project cost estimates. Do you realize the importance of having expert judgment? Same goes with many other processes during the course of project lifecycle from defining scope to identifying risks. Expert Judgment as defined in some books is basically, - Using knowledgeable groups or individuals to assist in project decisions.

Who is part of the Expert Judgment Group?

Typically someone outside of the project team. It could be one person or a group of people. They could be SMEs, Team Leaders, a separate department within your organization or even external consultants. They will be an expert either in a specific knowledge area, a specific discipline, an industry etc.

How is Expert Judgment different from Organizational Process Assets (OPA)?

OPA is related to the processes or artifacts. It is also a part of the organization and built on earlier experiences and lessons learned while Expert Judgment could be a group of people totally unrelated to the project.

Facilitated Workshops | Product Analysis | Alternatives Generation - Define Scope Tools and Techniques

There are three tools and techniques of the Define Scope process,

1. Facilitated Workshops

Going over the requirements collected in the collect requirements process with all the stakeholders at the same time can help narrow down on the project scope. Facilitated Workshops is thus one of the most important tools and techniques of Define Scope process.

One of the most important objectives of this technique is to ensure that the requirements have quantifiable goals,

Jack – We need to make sure with this project our product gets easier to use
Jill – Our goal is to reduce customer support requests by 15%

Obviously, what Jill has mentioned is quantifiable and can be measured

2. Product Analysis

While collecting requirements, stakeholders are inclined to talk about requirements from the perspective of the product perspective and not the project perspective.

As an example – "The website is graphics intensive and loads slowly, we need a less graphics intensive website that should load quicker."

This is a product requirement. With the product analysis technique, we convert these product oriented requirements into the actual project work.

Continuing the above example – "Graphics team needs to come up with lighter graphics for the website."

3. Alternatives Generation

As the name goes, coming up with other ways of accomplishing a job is the whole concept behind this technique. This is a technique of the Define Scope process because it may lead to a change in the scope (or other project constraints)

Consider an example – Can the existing IT infrastructure with another department be used for 2 weeks to meet the testing requirements of the project?

- It might lead to realignment of the project dates based on other department's preference
- It can help reduce the project cost of acquiring the IT infrastructure

As you can see an alternative can lead to change in schedule and cost in addition to reduction of scope

Check more articles on Scope Management

Rita Mulcahy 9th Edition Out - Based on PMBOK Guide 6th Edition






Tomorrow is my PMP exam! | What should I be doing?

Vlog - Testimonial by a subscriber who cleared the PMP Exam

PMBOK 6 Online Course

Define Scope Process

The next process in Scope Management knowledge area (under Planning process group) after the Plan Scope Management and Collect Requirements processes is the Define Scope process.

Define Scope is the process of developing a detailed description of the project and product scope. A clearly defined scope is extremely important to project success. On the other hand, an ill-defined scope will eventually lead to conflict, rework and stakeholder discontentment. After the key process of Collect Requirements, it is only fitting that define scope process follows.

It should be noted that the scope of the project not just outlines what will be delivered as part of the project but it also emphasizes whatever that is excluded from it will NOT be delivered. So define scope can also be considered as drawing the boundary of the project and finalizing the project scope.

Check more articles on Scope Management

Requirements Traceability Matrix (RTM)

The Requirements Traceability Matrix (RTM), as the name goes, is all about "tracing" the requirements end-to-end. End-to-end here means right from the inception to design to code to test to acceptance so that they don't get 'lost' during the course of project.

Generally speaking, the Requirements Traceability Matrix is a one-stop-shop for anyone to look into and understand where the requirements come from, where do they get implemented and how do they get verified. It is the most convenient way for someone to take a quick high-level look at any requirement and make sure it is mapped to the corresponding design, code element and test case.

The most important task of the Requirements Traceability Matrix is thus to track all requirements and ensure whether or not they are being met by the current process and design. It also helps ensure that all system requirements have been met during the Verification process.

It is suggested that the Matrix be created at the very beginning of a project as it forms the basis of the project’s scope and incorporates the specific requirements and deliverables that will be produced. The Matrix also comes in handy during the Change Management process as it ensures any change in requirements is not interfering with other requirements. In addition to that, the matrix is also a helpful tool for the Quality Management process.

There are certain software like Quality Center that can generate RTM. Additionally, organizations may also have their own software to generate RTM.

All in all, the RTM shows the connection and relationship between initial requirements of the project and the final product/service produced.

Check more articles on Scope Management

What does a PMP Certified Project Manager do differently?

Below are the top 3 things a PMP Certified Project Manager does differently than a Non-PMP Certified Project Manager,

1. They apply the industry best practices

2. They stay abreast with what's happening in the world of Project Management

3. They understand the importance of Organization's Project Management database




Collect Requirements Tools and Techniques - Questionnaire, Observation and Prototype

As part of the Collect Requirements Tools and Techniques, we have covered majority of the ground and in this last leg we will be looking into three more tools that are used,

1. Questionnaire
Questionnaires are most helpful when each stakeholder (and possibly even the customers) can’t be reached in person. A questionnaire can always be circulated online to seek feedback and collect requirements

2. Observation
A feedback, although very crucial, might not always correctly represent what a user actually needs. Observing users while they are using the product can thus be much more insightful

3. Prototype
A prototype is basically a model of the product that should give the stakeholders a good idea of what to expect. Users do come up with requirements while they use the prototype which no one would have thought of earlier and this avoids significant number of change requests. Ofcourse, prototype suits agile or iterative model of software development much more than the waterfall model

Check more articles on Scope Management