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.