4squareviews

1.  Introduction

This series of posts assumes that you have already memorized the names of the 47 project management processes, and you are ready to go on to the task of memorizing the tools & techniques.    This post covers chapter 5 of the 5th Edition PMBOK® Guide, the Scope Knowledge Area.

2.   Scope Knowledge Area Processes

Here is a chart summarizing the six processes of the Scope Management Area, the first four of which are in the Planning Process Group, and the last two of which are in the Monitoring & Controlling Process Group.

3.   Integration Knowledge Area Tools & Techniques

Okay, let’s take 5.1, and 5.2-5.6 first, and discuss the most complicated process as far as tools & techniques are concerned, 5.2, last.

a.  Expert Judgment (5.1 Plan Scope Management and 5.4 Create WBS)

When planning scope management, or breaking down the scope to more manageable components, it is very helpful to get people who have done this before.    If your project is similar to ones done in the past, either by someone in your own organization or by someone in the industry, you can consider that person a Subject Matter Expert or SME for the purpose of planning your project’s scope or breaking it down to smaller, more manageable components.   That’s why this tool & technique is used for these two processes.

b.  Meetings (5.1 Plan Scope Management)

When you are doing planning, especially when it deals with one of the triple constraints of time, cost and scope (as in this case), having the entire project team working together on the task is important.   It is important not just to make sure that nothing essentially is left out, but also for reasons of group cohesion:   by having everybody involved, it is easier to get “buy-in” from all team members because they were all involved from the very beginning of the formal planning process.

c.  Inspection (5.5 Validate Scope)

This should be an obvious tool of “validate scope” because how else are the customers (or sponsors) going to figure out whether the deliverable meets their requirements and expectations?

d.  Variance Analysis (5.6 Control Scope)

The fact that variance analysis is used to figure out the difference between the planned scope and the actual scope should give you the clue that this is used when monitoring the scope.

e,  Decomposition (5.4 Create WBS)

The word “breakdown” in Work Breakdown Structure should be a clue as to the “Decomposition” technique.

f.  Group decision-making techniques (5.2 Collect Requirements and 5,5 Validate Scope)

The need for a group to make a decision on the requirements comes from the fact that after gathering all of the requirements (which is done with a lot of the other tools & techniques used for process 5.2 Collect Requirements), some of them will have higher priorities among certain stakeholders and some of them may even conflict.    In short, you may be able to please everybody, so a decision has to be made, and that is where the group decision-making comes into play.

The 5.5 Validate Scope process needs a group decision for this reason.   Let’s say the deliverable has been inspected, and the results of the inspection are known.   Does the deliverable meet the requirements and/or needs of the customer?    The customer needs to validate the deliverable if it does meet those needs, and then the customer needs to formally accept the deliverable and transmit this acceptance to the organization doing the project.    This acceptance is crucial for the project to succeed, so it is important that it be done carefully, ideally with representatives from the organization and the customer’s organization present.    That is why group decision-making is a technique for this process.

g.  Product Analysis (5.3 Define Scope)

h.  Facilitated Workshops (5.2 Identify Requirements, 5.3 Define Scope)

In both of these areas, you need a cross-functional and common understanding–in the first case of 5.2 Identify Requirements of the product requirements, and in the second case of 5.3 Define Scope of the project scope.   What is the product that is going to be built, and what will it require to make that product?    This is the reason to use a facilitated workshop, because they involve key players with a variety of fields of expertise.

i.   Interviews, focus groups, group creativity techniques, questionnaires and surveys, observations, prototypes, benchmarking, context diagrams, document analysis (5.2 Identify Requirements)

All of these techniques are for coming up with the various requirements, either from individuals (questionnaires and surveys, interviews), from groups (focus groups, group creativity techniques).   Observations show how the product is normally used so that the new product will be “user-friendly” rather than just “what the engineers want to put in the product”.    Past products are also referred to in the “benchmarking” technique to see what is already out there in the market.   This analysis is also helped by document analysis of things like owner’s manuals, or marketing literature connected with current products.   A “context diagram” shows how the product fits into the business in general, and shows how various parts of the business interact with it.    These techniques help identify the requirements, and help identify which stakeholders “own” which requirements.    Once you understand what the identify requirements process is, you should be able to name a couple of these techniques.

So, the most complicated process you can see is 5.2 Identify Requirements, which has the most unique tools & techniques.   Some tools & techniques such as expert judgment and group decision-making techniques are used for two different processes.   The rest of the processes are unique to a single process, and it should be obvious from the tool and/or technique which process it is associated with.

The tools & techniques for analyzing scope are more abstract than the ones for analyzing the schedule or budget, and thus take a little mental work to get straight in one’s head.   But once you do, memorizing the tools & techniques for the scope management knowledge area should not prove to be too difficult.

The next post will go onto the next of the so-called “triple constraints”, that of Time Management, covered in chapter 6 of the PMBOK® Guide.

Filed under: Uncategorized |