DAYS

HRS

MIN

SEC
Flat 70% off on elearning bundle courses
All Courses
Login / Sign up
Get started

By signing up, you agree to our Terms of Use and Privacy Policy.
Reset your password
Enter your email and we'll send you instructions on how to reset your password.

Scope Management Process

The PMBoK guide describes the scope management process as:

Collect Requirements

Stakeholders of a project play a very critical role in providing project requirements. Requirements are the need for any project or a product. Requirements should be able to fulfill the stated objectives. Requirements should not be included just because someone wants it. Requirements may be related to Quality, the business process, regulatory requirements, compliance, project management, among others. All of the requirements (including products and process) are taken into consideration by the Collect Requirements Process. The initiating phase involves defining the high-level requirements of the project and product during the project charter phase. The Collect Requirements process goes into the details of seeking additional and more specific inputs on those requirements and any related supposition from all stakeholders. Any miss in gathering these requirements may result in the failure of the project or may result in many changes or may even result in conflicts throughout the project journey. Hence, this process of collect requirements is critical. Identification of project stakeholders is the first step before collecting requirements. You can use a stakeholder register to record this information.

The next step is to collect requirements from stakeholders. Do you think, it will be that easy to collect requirements? For certain projects, there could be multiple hundreds of stakeholders. Likewise, even the methods required for collecting those requirements may be different for different stakeholders. The project manager needs to engage devoted effort to collect all the requirements before work is initiated on the project. If this is not done appropriately, a large number of changes are required on the project leading to high cost and high efforts. Reviewing historical information and lessons learned could be involved in the effort of collecting requirements. The project manager makes a conscious choice to choose the most appropriate technique for the project and the stakeholders. Identification of risks during the risk management process could also use the same techniques of collecting requirements process.

Now we move on to the Tools & Techniques.

This is quite a long list.

  1. Expert Judgement: 

    It is a very common input. It is the input from individuals or groups specialized knowledge or training in:

    Business analysis – so they will know how to drill down for business analysis

    Requirements elicitation – so they can extract the implied needs from the customer, as well as the stated needs

    Requirements analysis – so they can make sense of what they uncover

    Requirements documentation – so they can record the list of requirements

    Project requirements in previous similar projects – so they can apply a “reasonableness check” to the requirements and perhaps even suggest missed requirements.

    Diagramming techniques – so they can present the information in a meaningful way 

    Facilitation – so they can assist stakeholders and the team to work together efficiently, and 

    Conflict management – so they can help prevent the stakeholders fighting over requirements.

    On a medium to large scale project it is extremely unlikely that you will find one individual with all of these skills, so you will need to choose people as required to make sure all your bases are covered.

    And a huge tip here. As you proceed through each of these processes and benefit from the lessons learned from previous projects, please make sure that the team records lessons learned from this project, for the benefit of future projects. And the second big tip is -- don’t wait until the end of the project to record the lessons learned. Record them as you go because in the end you will have forgotten them or misremembered them, and people with important lessons will have left the team.

  2. Data Gathering:

    It is a bunch of data gathering Tools & Techniques. These include:

    Brainstorming: It is a way of extracting information from a group by using techniques to generate and filter ideas. For example, on several projects, I have used De Bono’s “thinking hats” system.

    Interviews: This is usually one or more interviews talking directly with stakeholders, individually, and asking questions from a script. As well as extracting information, this technique is also useful for detecting and eliminating misinformation. And when used correctly -- especially one-on-one – it helps reduce fear in the subject, especially when the information is confidential or potentially harmful. This way you can elicit information that would not be revealed in an open forum.

    Focus Group: Unlike an interview, a focus group is intended to get people talking together and interacting. And in this case, there should be a moderator or facilitator, who just sets the ground rules and keeps the conversion headed in the right direction. This tool works best when all the people in the group are familiar with the proposed product, service, or result, and its business need, along with subject matter experts.

    Questionnaires and Surveys: Questionnaires and surveys are of use when you need input from a large number of people, and or they are physically far apart, and it would be too inefficient to interview them or bring them together for workshops. Sometimes the results from questionnaires and surveys can be further refined in by interviews of small groups.

    Benchmarking: The final data gathering is benchmarking. Whenever you see the work “benchmarking”, always think of comparing similar things.

    In this case, you can compare the required products, services or results, with other similar offerings in the marketplace – or even within the same organization -- to see if the requirements could be improved.

  3. Data Analysis:

    The next input is Data analysis, and in particular, Document analysis.

    This is used to analyze existing documents to find clues about the requirements. A list of possible documents to check is listed on Page 143 of the PMBOK Guide.

    By this stage, we should have a lot of data. Some useful, and some not. We need to sort it out, filter it in some way and end up with a definitive list. 

  4. Decision making:

    The three techniques suggested for this are voting, Autocratic decision making and Multicriteria decision analysis.

    I will cover voting last.

    Autocratic decision making: Autocratic decision making means that one person makes all the decisions.

    Multicriteria decision analysis: Multicriteria decision analysis is an attempt to simplify the process, where various criteria are listed and ranked in a matrix.

    But, back to voting.

    Voting: This is a common method for allowing a group to make the decisions, even if there is a level of disagreement within the group.

    And within this technique there are 3 common versions:

    • Unanimity: This means that the motion is passed only if everyone in the group is in agreement.

    • Majority: This means that the option is selected if more than 50% of the members of the group agree. It helps to a group with an uneven number of members, so avoid a tie. Or a senior member may be appointed to have the “casting vote” where there is a 50-50 split.

    • Plurality: This means that the option is selected if the largest group is in agreement, even if the largest group is 50% or less. This doesn’t make sense if you have just 2 options unless voters are allowed to abstain. An example of the plurality is where you have 10 voters and 3 options. 4 vote for option 1, 3 for option 2, and 3 for option 3.

    Option 1 would be chosen because 4 is the largest group, but it is less than a majority (which would require 6 votes or more).

    The next Tools & Techniques are a strange bunch, so watch out for them on the exam.

  5. Data representation:

    Two suggested possibilities are:

    Affinity diagrams: Which enable similar ideas to be clustered into groups, and 

    Mind mapping: Which brings clarity to similarities and differences in proposed ideas.

  6. Interpersonal and team skills, including:

    Nominal group technique: It is a structured form of brainstorming, which enables suggestions to be ranked, and you can read about it on pages 144 and 145 of the PMBOK Guide.

    It is easy to understand. But the only thing I don’t understand about it is why is it included in Interpersonal and team skills, instead of Data Gathering techniques. 

    Observation/conversation: This is also known as “job shadowing” because basically, it is similar to spying on people as they do their work. It’s a useful technique when people are either unwilling or unable to describe their duties. Again it’s easy to understand, but again it is hard to see how this fits in with Requirements Gathering.

    Facilitation: “Facilitation is used with focused sessions that bring key stakeholders together to define product requirements. Workshops can be used to quickly define cross-functional requirements and reconcile stakeholder differences. Because of their interactive group nature, well-facilitated sessions can build trust, foster relationships, and improve communication among the participants, which can lead to increased stakeholder consensus. In addition, issues can be discovered earlier and resolved more quickly than in individual sessions.” (PMBoK Guide p145) Please check out page 145 because it gives 3 examples of facilitation: “Joint application design/development, Quality function deployment, and User Stories. These are well explained in the PMBOK Guide, so I can’t really add anything to them, however, they appear quite frequently in the exam.

  7. Context diagrams:

    A context diagram is a diagrammatic representation of ahigh-level product scope, within the business context. It shows how “actors”, which means people and other systems interact with the product.

    You will find an example of a context diagram on page 146 of the PMBOK Guide.

  8. Prototypes:

    A prototype was originally a small-scale working model of the final product, and is obviously vastly cheaper to produce, and it enables a number of problems to be detected early in the project, to enable the product to be redesigned. It’s also a great opportunity for stakeholders to get a “taste” of the final product, and might stimulate more ideas.

    Nowadays a computer generated 3D model can remove the need for building a model, or of course if you need a physical model, it can often be 3D printed.

    There is a hidden trap in prototypes, which is related to the trueness of the model.

    Many years ago I was working on a project in Ireland for a textiles group. One company wove Genuine Irish Linen, from flax which came from Russia, another company wove synthetic fabrics, another performed offset printing of fabrics, and the last made synthetic leather jackets and boots.

    The company that made the jackets and boots, produced synthetic leather, which was made from vinyl, and they also produced thin foam sheeting and woven nylon fabric. They sent the synthetic leather, foam and nylon fabric to an outside company, which bonded the synthetic leather to the foam, then bonded the nylon fabric to the back. The jackets and boots were then cut from this bonded material.

    The bonding process was very expensive, so the company initiated a project to find a cheaper way to do it.

    They mailed out enquires to a number of companies in Ireland, which experience with glueing and bonding machinery.

    One of the companies made a prototype of a machine for bonding the fabrics. This was demonstrated to the project team, and everyone was very happy with the outcome.

    But unfortunately, the owner of the group of companies got involved in the process. And instead of contracting the outside company to build a full-size bonding machine, the CEO bought the outside company. His logic was that his group could now make a fortune doing bonding work for other companies.

When we study Risk Management later in the course, one of the risk treatment strategies we will cover is called “Transference”. This means attempting to give the risk to someone else, usually by outsourcing or insurance.

But the trap to Transference is that the people you are transferring to just be external to your organization because an organization still owns all the risk from its employees.

It the group had contracted the outside company to build the full-size machine, this would have transferred the risk to the outside company.

But buying the outside company means that it is now an inside company, and the Group owns the risk.

I will omit the details of the long, sad story, but the punchline is that although the prototype worked perfectly, the full-size machine was a failure.

The CEO kept pouring money into the company, trying to get the machine working, but he paid so much, the entire group went bankrupt.

So make sure your prototype is a true representation of the final product.

Requirements Documentation: 

One’s the team collect all requirements, it is time to document them. The documentation should be clear and unambiguous. This documentation is an output of Collect Requirements Process. If the representation of information is not done appropriately, the collected requirements may be misunderstood. Hence, it is advisable to NOT assume that the collected requirements will meet the objectives. Thus, it is important to ask the stakeholders if the collected requirements would be meeting the stated objectives. This helps ensure that the right requirements are collected and end output will be acceptable.

 

The following section contains PMBOK v5 content and it is not applicable to PMBOK v6.

The PMBoK guide describes the scope management process as:

Determine Requirements:

The project charter describes the project’s business case. The project manager should ensure that all requirements support the project’s business case. Needs of the stakeholders should be taken into consideration while defining the product and project scope. WBS to be used to break the scope into smaller and more manageable pieces. Scope management process should be created from the customer’s viewpoint. Scope performance is to be measured and adjusted as needed during the course of the project.

Collect Requirements

Stakeholders of a project play a very critical role in providing project requirements. Requirements are the need of any project or a product. Requirements should be able to fulfill the stated objectives. Requirements should not be included just because someone wants it. Requirements may be related to Quality, the business process, regulatory requirements, compliance, project management, among others. All of the requirements (including products and process) are taken into consideration by the Collect Requirements Process. The initiating phase involves defining the high-level requirements of the project and product during the project charter phase. The Collect Requirements process goes into the details of seeking additional and more specific inputs on those requirements and any related supposition from all stakeholders. Any miss in gathering these requirements may result in the failure of the project or may result in many changes or may even result in conflicts throughout the project journey. Hence, this process of collect requirements is critical. Identification of project stakeholders is the first step before collecting requirements. You can use a stakeholder register to record this information.

The next step is to collect requirements from stakeholders. Do you think, it will be that easy to collect requirements? For certain projects, there could be multiple hundreds of stakeholders. Likewise even the methods required for collecting those requirements may be different for different stakeholders. The project manager needs to engage devoted effort to collect all the requirements before work is initiated on the project. If this is not done appropriately, a large number of changes are required on the project leading to high cost and high efforts. Reviewing historical information and lessons learned could be involved in the effort of collecting requirements. The project manager makes a conscious choice to choose the most appropriate technique for project and the stakeholders. Identification of risks during the risk management process could also use the same techniques of collecting requirements process.

Reviewing Historical Records

Historical records and lessons learned are very critical for the project team that helps in gaining an understanding of what were the requirements on similar projects and thus, help identify relevant processes. It also helps a new person understand expectations from the respective teams. Lessons learned from other projects may highlight common mistakes done by other project managers in defining the area of scope to ensure such requirements are not missed on current projects.

Interviewing In the PMP exam, this technique may also be called as “expert interviewing”. Various methods of interviews could be conducted by the project manager with project stakeholders to identify their requirements for the product or the process. The interviews can be conducted as one-on-one, emails, phone calls, group setting, letters or any other method.

Focus Group In a focus group, the moderator or the facilitator plays a key role to gather inputs and thoughts that helps get the opinions and requirements for the product or an aspect of the project from a specific set of stakeholders or subject matter experts.

Facilitated Workshops :

The process of bringing together the individuals / stakeholders of different perspectives to define the requirements of the product or service is called as facilitated workshops.

BRAINSTORMING

The method of brainstorming strives for “group think”. It really does not just mean a meeting with people to discuss ideas or seeking individual thoughts. Brainstorming helps produce large number of ideas in a short period of time. A participant of the brainstorming session can share an idea of determining the scope. That idea generates an idea from another participant which leads to yet another idea, and so on. The participants of a brainstorming session can vary. Individuals from different functions, backgrounds and perspectives can benefit the brainstorming session in a great way. The participants need not be just the individuals from the organization, they could be from outside the organization as well.

Nominal Group Technique

This technique is done in continuation to the brainstorming meeting where the ranking of the most powerful ideas is done by the meeting participants.

Delphi Technique

This is a consensus technique with a difference. In this technique, the participants do not meet each other. A request for information is sent to the experts and their participation details are kept anonymous. Their responses are compiled, and the results are sent to back to them for further review until a final consensus is reached.

Mind Maps

A mind map diagram is used to generate ideas and classify them into logical groups. It is a tool used to visually organize the information. Many ideas are connected directly to the central core idea, and other ideas branch out from these.

Questionnaires And Surveys

A questionnaire is designed to seek responses from respondents. The benefit of questionnaires and surveys is that it can be sent out to a large group.

Prototypes

A model of the proposed product is a prototype. Stakeholders are presented the prototype to seek feedback. Multiple versions of the prototype may be created till all the requirements are captured, the model is finalized and approved.

Group Decision-Making:

There are multiple ways to make decisions in a group. Requesting inputs from all stakeholders may result is generating multiple ideas. These ideas may lead to confusion and may also lead to conflicts. They need to be reviewed, analyzed, approved or rejected and prioritized before recording them in project documents. A unanimous agreement on a requirement from the group makes the decision making easy. A single person making a decision for the entire group is known as the dictatorship technique. This has an advantage of quick decision making, however, also has a disadvantage of other stakeholders not agreeing in decision making done by the individual.

In group decision-making, there are many conflicting opinions. In these situations, groups may take a majority approach. In this technique, the group takes a decision which is supported by more than half of the members. In case there is no majority support, the group may go with the decision of a largest number of supporters. This is known as plurality technique. There is another technique known as the consensus approach. In this technique, the decision is made which is acceptable for the group. In case if there are certain members of the group who did not support the decision, they will willingly accept that most members of the group support.

Requirements Documentation: 

One’s the team collect all requirements, it is time to document them. The documentation should be clear and unambiguous. This documentation is an output of Collect Requirements Process. If the representation of information is not done appropriately, the collected requirements may be misunderstood. Hence, it is advisable to NOT assume that the collected requirements will meet the objectives. Thus, it is important to ask the stakeholders if the collected requirements would be meeting the stated objectives. This helps ensure that the right requirements are collected and end output will be acceptable.



1 Comments

mayukh saha 2019-11-13 20:56:18 +0530

good

Add Comment

Subject to Moderate