4squareviews

Here’s a trick question:   what is the output of the “Create WBS” (Work Breakdown Structure) process?   If you answer “the WBS” on the exam, you will get it wrong.   The correct answer technically is “the scope baseline”, but that is only because the result of the “Create WBS” is both the “WBS” and the “WBS Dictionary.”   These two components, plus the Project Scope Statement, which is the output of the last process 5.3 Define Scope, all are included in what is called “the scope baseline.”    So please remember that the scope baseline is not one document, but three separate documents combined!

Okay, let’s discuss the outputs to the proces 5.4 “Create WBS”.

5.4.3 Create WBS:  Outputs

5.4.3.1  Scope Baseline

Remember my analogy from a previous post:   the scope is like a series of blueprints for a building under construction that contain several layers of detail:

• the requirements, analogous to the structural elements of a building  like the scaffolding of the building and its foundation,
• the major deliverables, analogous to the walls, ceiling and floors that connect the structural elements and give the building a shape,
• and the WBS which gives the minor deliverables all the way down to the work package elements, analogous to the furnishings, etc. that will go into the individual rooms.

The scope baseline includes the:

• Project scope statement–this contains a description of the project scope, the major deliverables, plus the assumptions and constraints that put a boundary around the scope (the analogous to the second level of detail of the scope listed above).
• WBS–this contains a breakdown of the total scope of work (the third level of detail of the scope listed above) into work packages that needs to be carried out in order to create the deliverables (the second level listed above) that fulfill, in turn, the requirements (the top level listed above) of the project.    As mentioned in the last post on how to create the WBS, there may be some control accounts included in the WBS which are used to help keep track of a group of related work packages for the purpose of measuring the performance of that part of the project.
• WBS dictionary–for each element of the WBS dictionary, which describes the work that needs to be done, consider the WBS dictionary the “flip side” of that work package which contains information on the costs, schedule, resources and other information needed to do that work.

5.4.3.2  Project Documents Updates

Both the assumption log (output of process 4.1 Develop Project Charter) and the requirements documentation (output of process 5.2 Collect Requirements) may be updated with items created or elaborated upon as a result of the Create WBS process.

Now that the scope is complete, it needs to go to the planning process of the next knowledge are, that of schedule management, in order to be implemented.   Now the scope is like a list of ingredients for a recipe, but a true recipe requires something else equally as important, if not more so:   the list of instructions on how to put it together!   That is where the process of creating the project schedule comes in, and that will be covered in the next series of posts on Schedule Management.

In the meanwhile, the next few posts will go on to cover the two processes in the next phase of processes for Scope Management, namely, 5.5 Validate Scope and 5.6 Control Scope.   The next post will take up the inputs to the first of these two processes, 5.5 Validate Scope.

Filed under: Uncategorized | Leave a comment »

“My life amounts to no more than one drop in a limitless ocean. Yet what is any ocean, but a multitude of drops?”–Cloud Atlas, by David Mitchell.

The process of decomposition of the scope done in this process is where the seeds of the miraculous “power of we” on a project are sown.   What do I mean?   A project is a large undertaking that, in some cases, would be impossible for one single, solitary human being to do on their own.   From the construction of the pyramids to the landing of a man on the moon, projects have succeeded because they take a huge amount of work–what is called the scope of the project in PMI language–and break it down into manageable parts that individual human beings can perform.   The project manager takes the individual human beings and puts them on a team so that they became a team with the “power of we”, that is, the power of doing more than any group of individuals of the same size could do on their own (the power of “I” alone).   When you are on a good team, as the poet Rumi once said:

“You are not just the drop in the ocean. You are the mighty ocean in the drop.”

The process of creating the work breakdown structure or WBS is called “decomposition” and it is the main tool and technique used in this process.

5.4.2 Create WBS:  Tools and Techniques

5.4.2.1  Expert Judgment

Of course, the people you will turn to in order to create the work breakdown structure are those with expert judgment, particularly those who have worked on similar projects.  Remember, a project team member who wants to avoid work may be lazy, but a project team member who wants to avoid unnecessary work that has been done before is smart.   The best place to look for your model of a WBS on a project in terms of the structure of the WBS is the procedures and templates for the WBS,  one of the organizational process assets that is an input to this process.    For the contents of the WBS, the best place to look would be project files and lessons learned from previous projects, again, some of the organizational process assets that are inputs to this process.  And the people that created those documents would be great experts to have as consultants for the creation of the WBS on your particular project.

5.4.2.2  Decomposition

There is only one main tool & technique for this process, and that is decomposition, which is the process of dividing the scope of the project from the level of deliverables, which are contained in the project scope statement (the output of the last process 5.3 Define Scope), to smaller, more manageable parts called work packages, which are the lowest level of the WBS for which cost and duration can be reasonably estimated and managed.

How does the process work?   For visual examples you may want to refer to while looking at these steps, see pages 158 and 159 of the PMBOK® Guide.

1. Look at the Scope Management Plan for guidelines on how your organization does the WBS (the plan should indicate how all of the scope management processses are to be done, not just this one).     The Scope Management Plan is an output of process 5.1 Plan Scope Management.
2. Look for the templates for the WBS that your organization may use (these are some of the organizational project assets that are an input to this process).    You will use these templates to create the WBS based on instructions contained in the Scope Management Plan.
3. Look for the deliverables of the project scope in the Project Scope Statement, which is the output of the previous process 5.3 Define Scope.   Remember the scope is developed first at
   • the level of requirements (high-level requirements are in the Project Charter, more detailed requirements are developed in the Collect Requirements process 5.2 and placed in the Requirements Documentation)
   • the level of deliverables (the Define Scope process 5.3 develops the deliverables that will fulfill those requirements), and then finally
   • the level of work packages (this process 5.4 Create WBS takes the deliverables and breaks them down into work that a person can reasonably do in a matter of hours).
4. Okay, now let’s build the WBS!   The top level is the name of the project itself.
5. The second level will any phases of the project life cycle if the project is broken up that way (design, creation of prototypes, testing, etc.).
6. The product and project deliverables are the next level of decomposition, which can organized by the requirements they relate to.    These can be further subdivided into “major deliverables” and “deliverables” based on the complexity of the project.
7. The deliverables are further broken down until they reach the lowest level, that of work packages.
8. Once the decomposition of the deliverables is verified as appropriate, then you can develop and assign identification codes to the components of the WBS, where the first level has the identification 1.0, the second level has the identification 1.1, 1.2, 1.3, etc., the third level has the identification 1.1.1, 1.1.2, 1.1.3, etc.   This identifies the level to look for any particular component and which component is the “parent” of any particular component.    The parent is the component which is broken down into subcomponents at a lower level.
9. Once the work packages have all been uniquely identified, you can start adding “control accounts” associated with a group of associated work packages.   These are used in the monitor and control phase and contain a hierarchical summation of the costs, schedule, and resources used for that group of work packages.
10. For those work packages which are not done immediately, or are as yet without detailed estimates of schedule, cost, or resources, you can create “planning packages” which essentially are a way of saying TBD or “TO BE DETERMINED”.
11. Additional information on each work package can be compiled into something called the WBS dictionary, which is information created from other processes in other knowledge areas that supports the scope information contained in the WBS.

That is the detailed process of creating the WBS.   The outputs of the process are described in the next post.

Filed under: Uncategorized | 1 Comment »

After my brief introduction in the last post to what a Work Breakdown Structure or WBS is, let me now turn into what inputs are required to actually creating one.

5.4.1  Create WBS:  Inputs

5.4.1.1  Project Management Plan

The relevant component of the Project Management Plan namely, the Scope Management Plan, should spell out how to do all the other processes in he scope knowledge area, including this one, process 5.4 Create WBS.

5.4.1.2  Project Documents

The project documents used as inputs into this process are

• Project Scope Statement–output of process 5.3 Define Scope
• Requirements Documentation–output of process 5.2 Collect Requirements

5.4.1.3 Enterprise Environmental Factors

• Industry-specific WBS standards–these are standards that are relevant to the nature of the project that may serve as external reference sources for creating the WBS,

5.4.1.4 Organizational Process Assets

• Policies, procedures, and templates for the WBS (usually maintained by the Project Management Office)
• Project files from previous projects (again, why re-invent the wheel?)
• Lessons learned from previous projects

In the next post, I will discuss the tools and techniques for this process, the main of which is decomposition, or the process of breaking down the scope from the deliverables listed in the Project Scope Statement (the output of process 5.3 Define Scope) down to the smaller, more manageable elements called work packages.

Filed under: Uncategorized | Leave a comment »

The Work Breakdown Structure or WBS is one of the most powerful tools in project management.   Before going into the inputs, tools & techniques, and outputs of this process, I wanted to use this post to make a few introductory remarks about the WBS.

The process of creating the WBS is where you take the project deliverables and break down or subdivide the project work into smaller, more manageable components called work packages.   As the PMBOK® Guide puts it, “it provides a framework for what has to be delivered.”

Elaborating on this concept of framework, I can elaborate on an analogy I used in an earlier post.   What is the relationship of the requirements (output of process 5.2 Collect Requirements), the deliverables (output of process 5.3 Define Scope), and the WBS (output of this process 5.4 Create WBS)?   Think of a set of architectural blueprints for a building.    The structural components, like the steel beams that make up the scaffolding of the structure, plus the foundation of the building, are what hold the building up.   These are like the requirements, and are the first elements that will be built.   Next are the connecting structures, like the roof, walls, and floors, which hold the building together into a single connected space.   The deliverables are like this next level of detail in the architectural drawings:   they give shape to the building as a whole.    Finally, the WBS is like the detailed drawings of the interiors of the rooms, including furnishings etc. the next and final level of detail of the architectural blueprints.

But understanding what a WBS is NOT is as important as understanding what it IS.   The resulting WBS looks like an organizational chart, with the top level being the largest components, and the bottom level being the smallest components or work packages.  However, it is not a flowchart; it doesn’t show you HOW to actually do the project.   It is, to use another analogy, like the ingredients in a menu.   To actually create a dish from a recipe you need not just the list of ingredients, but the instructions on how to mix them together, etc.   That is the schedule, and is the subject of another knowledge area, that of Schedule Management.    The WBS is one of the inputs for creating the schedule, but it is not the schedule itself.

Okay, with those preliminary remarks out of the way to set up the relationship between the outputs of scope management we have seen so far–the requirements, the deliverables, and the work packages as part of the WBS, let’s go into the inputs of this process in the next post.

Filed under: Uncategorized | Leave a comment »

In the last post, I discussed the tools and techniques used, in particular that of product analysis, which takes the requirements and translates them into meaning deliverables (i.e., the scope) that are needed to deliver the final product that fulfill those requirements.   Those deliverables are what get put into the Project Scope Statement, the major output of this process.    The process also creates updates to some of the project documents.

The PMBOK® Guide makes an important point in that some elements of the project charter seem, at first glance, to be the same as those in the project scope statement, but those elements which are similar are at a high or more general level of detail in the project charter, whereas those in the project scope statement are a greater level of detail.   I will note those distinctions below…

5.3.3  Define Scope:  Outputs

Here are the elements of the project scope description.

1. Product scope description–a narrative description of the characteristics of the product, service, or result of the project.   At the high level of the project charter, this product description is sometimes referred to as the “statement of work”, essentially the “seed idea” of the project.   But in the project scope statement it is elaborated further.
2. Deliverables–a deliverable is defined as “any unique and verifiable product, service, or result that is required to be produced to complete a process, phase, or project.   These deliverables are the “building blocks” of the project that when completed create the final deliverable which is then validated by the customer in the 5.5 Validate Scope process.   The equivalent category in the project charter are the high-level requirements–these are exactly what are translated as a result of this process into the deliverables that go into the Project Scope Statement.
3. Acceptance criteria–the set of conditions that is required to be met before deliverables are accepted.
4. Project exclusions–In July 1963 “The Plain Dealer” of Cleveland, Ohio published an article titled “Why Are Elephants?” with several cartoons and jokes on the theme of elephants.   The following quip described a common sense approach to creating a sculpture:
   

   “How do you make a statue of an elephant? Get the biggest granite block you can find and chip away everything that doesn’t look like an elephant.”

   This was obviously meant to be humorous because you can imagine the bewildered art student hearing that sage advice and finding it not very helpful at all.   However, when you are creating the project equivalent of a huge elephant, sometimes it is helpful at the beginning of the project to state explicitly what is not going to be in the scope.   This helps prevent unnecessary changes because you can point to this exclusion when someone decides to try to add that particular scope during the course of the project.   Now you can include exclusions in the project charter as part of the larger category of boundaries, which are requirements which are going to be in the scope, but can also include those features or characteristics which are not going to be in the scope.   This can be because they are envisioned to be part of a future project if the current project is successful, or because the excluded features are explicitly not wanted by the sponsor.    Putting such exclusions in the project charter as part of the boundaries can be pretty persuasive to those suggesting adding those features to the scope, because now rather than having to argue with the project manager to include them, they now have to talk to the project sponsor!

5.3.3.2  Project Documents Updates

• Assumptions log–sometimes the Define Scope process of turning requirements into deliverables uncovers additional assumptions or constraints that were not previously apparent when the project scope was at the more abstract level of requirements.
• Requirements documentation–sometimes the review of the requirements may result in adding requirements, or changing the requirements themselves, and these changes or additions are added to the requirements documentation, which can include the requirements traceability matrix.
• Stakeholder register–when new information about the stakeholders comes to light during their participation in this process, particularly their views about the various requirements they care about, it is recorded in the stakeholder register.   It should be listed there whether they are to be consulted regarding a decision involving the requirements, or whether they should be informed afterwards regarding a decision involving those requirements.

Filed under: Uncategorized | Leave a comment »

In the last post, I discussed the inputs that go into this process.   In this post, I will discuss the tools and techniques themselves.

The first four tools and/or techniques are “generic” in the sense that they are used in ANY decision-making process on a project; however, I will list the examples of these tools that are applicable to this particular process.    The fifth technique, Product Analysis, is used specifically for this process.

5.3.2.1  Expert Judgment

The best experts to use in this process are those that have done similar projects before, as they can help guide the planning process from the requirements, the output of the last process, to the scope required to deliver those requirements.

5.3.2.2  Data Analysis

Alternatives analysis is a data analysis technique used to evaluate the various ways to meet the requirements listed in the requirements documentation and the high-level project objectives identified in the product charter.

5.3.2.3 Decision Making

• Multicriteria decision analysis– this provides a systematic analytical approach to establishing criteria, in particular the constraints such as schedule, budget, and resources, to rank the various alternative ways to meet the requirements.

Once the analysis is complete, then it is time to make a decision.   This can be done either through autocratic decision making, where one individual takes responsibility for making the decision for the group, or some sort of system of voting as a group, which may include the following decision-making techniques:

• Autocratic–one person takes responsibility for making the decision for the group

• Unanimity–everyone must agree on a single course of action in order for it to go forward.
• Majority–more than 50% of the members have to support a single course of action in order for it to go forward.
• Plurality–the largest block of votes in a group decides on a single course of action in order for it to go forward.
• Autocratic–one person takes responsibility for making the decision for the group

5.3.2.4  Interpersonal and Team Skills

These skills are important for facilitation of workshops and working sessions with key stakeholders.   The goal is to reach a cross-functional and common understanding of the project deliverables and project/product boundaries.   Boundaries, remember, are not just what is going to be in the scope, but exclusions, those items which are specifically NOT going to be in the scope.

5.3.2.5 Product Analysis

This process is the creation of asking questions and forming answers regarding the use, characteristics, and other relevant aspects of what is going to be delivered.

Each application area (IT, manufacturing, construction, etc.) has one or more generally accepted methods for taking high-level product or service descriptions (usually found in the project charter and/or business plan), capturing the requirements needed to fulfill these objectives (done in the last process), and then in turn decomposing the requirements into the level of detail needed to design the final product.    That last step is what is done in product analysis.

This can include

• requirements analysis (categorizing into business requirements and stakeholder requirements at a high level, solution requirements and quality requirements at a more technical level, transition and readiness requirements which deal with how the product, service or result will be implemented, and finally project requirements that analyze the various requirements of the project such as schedule, budget, and resource constraints
• analysis of the systems in which the product, service, or result will operate
• analysis of the value of the product, service or result to the various stakeholders including (most importantly) the customer

The result of this analysis, which uses the four tools and techniques listed above (expert judgment, data analysis, decision making, and interpersonal and team skills), is the project scope statement and updates to project documents.

All of these outputs to this process are described in the next post.

Filed under: Uncategorized | Leave a comment »

The last process 5.2 Collect Requirements not only collected the requirements, but analyzed, prioritized, and selects the final requirements that will go into the product, service or result that the project is going to create.

The requirements of a project are like the structural members of a building that provide the weight-bearing structure that holds the building up.    The scope of a project are the connecting structures of a building:   the walls, floors, ceilings, and windows that connect the building into a seamless space.

This process 5.3 Define Scope takes the final requirements that were decided upon as the output of the last process and develops a detailed description of both the product and the project that will create it.   It creates the boundaries of the product and project, listing not just what is going to be included, but what is going to be excluded.   Also, the acceptance criteria for the scope are developed so that in the process 5.5 Validate Scope, there is no room for misunderstanding between the customer who ordered the product and the organization that did the project to create it.

This post will cover the inputs to this process.

5.3.1 Define Scope:  Inputs

5.3.1.1  Project Charter

The high-level project description and list of product characteristics as well as approval requirements are provided in the Project Charter.   This is the first place to go for finding out about the scope of the project.

5.3.1.2  Project Management Plan

In particular, the Scope Management Plan component of the master Project Management Plan will document how to do all the scope management processes, including this one.

5.3.1.3  Project Documents

• Assumption log–created as an output of the same process that created the Project Charter, the assumption log identifies the high-level assumptions and constraints about the product, project, environment, stakeholders, and any other factors that may influence the project and product scope.   If these assumptions change, then it may cause the project and product scope to change as well.
• Requirements documentation–created as an output to the last process 5.2 Collect Requirements, this is where you should go (after the Project Charter listed above) to identify those requirements that will be fleshed out into the product and project scope during this process.   The requirements documentation may take the form of a Requirements Traceability Matrix.
• Risk register–created as an output to process 11.2 Identify Risks.   Sometimes a strategy to avoid or mitigate a certain risk may involve
  • reducing or changing project or product scope
  • hiring a vendor to handle a certain portion of the project or product scope that your organization doesn’t have the expertise to handle
  • entering a business partnership to work together with another company that has expertise with a certain portion of the project or product scope

5.3.1.4  Enterprise Environment Factors

The complete list of factors is listed on p. 152 of the PMBOK® Guide 6th Edition, but the factors that could affect this process 5.3 Define Scope include the following:

• the culture of an organization (is it leaning towards traditional project management methodologies, agile methods, or some hybrid in between)
• marketplace conditions (what are the competitors doing in this same area),
• the company’s infrastructure (which may determine if vendors are needed to handle some of the scope, or if the company needs to acquire additional resources for the project).

5.3.1.5 Organizational Process Assets

The organizational process assets that could influence the process 5.3 Define Scope are:

• Policies, procedures, and templates for a project scope statement (which should be included in the Scope Management Plan, the output to process 5.1 Plan Scope Management)
• Project files from previous projects (why re-invent the wheel?)
• Lessons learned from previous phases or projects (produce new mistakes this time around–don’t waste time repeating old ones!)

In the next post, we will go through the tools and techniques used in this process.   Like any decision-making process, these will include the generic tools used for such a process like expert judgment, data analysis, decision making, and interpersonal and team skills, but will also include a tool and technique called “Product Analysis” that is specific to this process.

Filed under: Uncategorized | Leave a comment »

Now that we have used process 5.2 Collect Requirements to not just collect, but to analyze, prioritize, and finally decide upon which requirements will go into the project, it is time to document them so that they can be referred to during the course of the project.   That is what this post is for:  to show the kind of documentation that you can use for requirements.

5.2.3.1 Collect Requirements:  Outputs

5.2.3.1 Requirements Documentation

All requirements should have the following characteristics–they should be …

• Unambiguous (measurable and testable)
• Traceable (someone should be assigned the responsibility for managing each requirement and there should be a stakeholder whom can be consulted if there are questions about the requirement)
• Complete
• Consistent (no contradictory requirements)
• Acceptable to key stakeholders

Here is a review from my post about the inputs to this process regarding the types of requirements a project can have.

1. Business requirements–these high-level requirements a) help the project align with the strategic objectives of the company, as well as b) assuring that the business need, i.e., the reason why the project has been undertaken, will be filled by the product, service or result that the project will create.   The source of these requirements can be found in the project charter and/or business case document.
2. Stakeholder requirements–These are requirements from a particular stakeholder or group of stakeholders.   These requirements are found by engaging with the stakeholders.
3. Solution requirements–What are the particular features, functions, and characteristics of the product, service or result that will meet the business and stakeholder requirements listed above.   Now we are getting into the details of what the product will turn out to be, and for that reason the source of these requirements will be subject matter experts.   There are two sub-types of solution requirements:
   • Functional requirements–what are the data, actions, or processes that the product should execute?
   • Non-functional requirements–these supplement functional requirements and describes the environmental conditions or qualities required for the product to be effective.   How reliable is the product?   How easy is it to use?   What technical or other support will it require for continued use?
4. Transition and readiness requirements–these are the temporary capabilities, such as a training requirements, that will need to be in place to transition to using the product.
5. Project requirements–these deal not with the scope of the product, as the categories above do, but with the scope of the project itself.    For example, what are the constraints on the budget and schedule?   (The quality requirements are a constraint that are dealt with in the category below.)
6. Quality requirements–scope is a constraint that deals with the completeness of the work, quality is a constraint that deals with the correctness of the work.    What are the conditions or criteria needed to validate the end result of the project?   Are there tests that need to be performed?   What is the inspection procedure going to consist of?   Is it important to get this spelled out at the beginning of the project so that the process of validation of the end result is a) objective and b) understood by the customer or the sponsor of the project.

So, these requirements range from the high-level (category 1) to the specific (category 3 and 4); stakeholder requirements (category 2) can be either high-level or specific.    The requirements can be related to either the scope of the product (categories 1-4) or the scope of the project (5-6).

Documentation of requirements should contain at a minimum

• the person responsible for managing the requirement
• the stakeholder to consult regarding the requirement
• the priority of the requirement

and can also contain additional explanations such as

• an executive summary of the requirement (for management)
• detailed descriptions of the requirement (for relevant stakeholders, subject matter experts, and project team members)
• attachments to illustrate or give further technical details on the requirement

One specific form of the requirements documentation is the requirements traceability matrix described in the paragraph below.

5.2.3.2  Requirements Traceability Matrix

The requirements traceability matrix is a grid that links product requirements to their origin (are they based on the project charter, the business case, specific stakeholders, etc.) and to the deliverables that satisfy these requirements.   It helps link the requirements to the business value of the project by linking to the business and project objectives.   By having them documented in this way, it helps the customer successfully validate (accept) the product at the end of the project.   And more importantly, it allows a framework for managing changes to the product scope during the course of the project.

Typical attributes used in the traceability matrix are:

1.  Identification–a unique identifier (001, 002, etc.), and a textual description of the requirement
2. Source–what business needs or strategic company objectives the requirements are linked to, or which stakeholder is the origin of the requirement (to consult regarding the requirement if necessary)
3. Owner–who is managing this particular requirement (usually someone on the project team or a subject matter expert)
4. Deliverables–what are the deliverables that satisfy the requirement
5. Status (approved, cancelled, active, assigned, completed)
6. Priority (used during the selection process, but can be referred to if changes need to be made during the course of the project)
7. Acceptance criteria (very important for the 5.5 Validate Scope process)

There is an example of what the Requirements Traceability Matrix looks like in Figure 5-7 on page 149 of the 6th Edition of the PMBOK® Guide.

The next process in elaborating the scope is 5.3 Define Scope, and that is the subject of the next few posts.

Filed under: Uncategorized | Leave a comment »

There are so many tools and techniques associated with this very important process that I have split the discussion into three posts.   The first post discussed the categories of requirements, the second one discussed the first four tools and techniques, namely,

• Expert judgment
• Data gathering
• Data analysis
• Decision making

which are tools and techniques that are used with any major decision-making process on a project, and not just this process related to requirements.

The next set of tools and techniques, the ones I am discussing in this post, include those that are specific to this process regarding requirements.

5.2.2  Collect Requirements:  Tools & Techniques (continued)

5.2.2.5  Data Representation

These techniques take ideas that are generated in brainstorming (one of the Data Gathering tools & techniques described in section 5.2.2.2 in the last post), and integrate them together.

• Mind mapping–this technique takes ideas that are generated in the brainstorming process and then tries to tie them together into a single map by reflecting those ideas which have things in common and can be categorized together
• Affinity diagrams–these allow large numbers of ideas to be classified into groups for review and analysis.   For details, please see my post that is specifically regarding this technique:

Six Sigma Green Belt—Management Tool #1: Affinity Diagrams

5.2.2.6  Interpersonal and Team Skills

These are tools and techniques which require interpersonal and team-related skills in order to carry them out, and usually have some sort of moderator or facilitator.

• Nominal group technique–This takes the ideas that were generated in the brainstorming process and then ranks them based on a voting process.   There are four steps to the process:

1. A question or problem is posted to the group.    Each person generates ideas related to that question or problem and writes them down.
2. The moderator collects the ideas generated in step 1 and writes them on a flip chart or whiteboard.
3. Each idea recorded on the flip chart or whiteboard that is created in step 2 is then discussed with the entire group.
4. Individuals vote to prioritize the ideas usually using a scale of 1-5.   The votes are tallied and the highest scoring ideas are selected.

For a more detailed discussion, please see my post that is specifically regarding this technique:

Six Sigma Green Belt: Team Tool #2—Nominal Group Technique

• Observation/conversation–one way to generate ideas on a proposed new product or service is to observe individuals using the current product or service and see how they perform their jobs and carry out processes.   You can also ask people about how they do their jobs, but many people do their jobs so automatically that it may be easier to observe what they actually do rather than having people describe what they do.
• Facilitation–these are focused sessions that bring key stakeholders together to define product requirements.    The following are examples of these focused sessions:
  • User stories–used in agile project methodologies, where the required functionality of a product is described in short descriptions called “user stories”
  • Joint application design/development–used in the software development industry
  • Quality function deployment–used in the manufacturing industry–for more details, please see my post that is specifically regarding this technique

Design for Six Sigma–Quality Function Deployment and the House of Quality

5.2.2.7  Context Diagram

A context diagram shows the business system that the new product, service or result will be operating in.   This diagram shows how people, processes, equipment, etc., work together.   There is a good example on p. 146 of the PMBOK Guide.

5.2.2.8  Prototypes

Especially in dealing with a new product or service, a prototype provides a model of the expected product which can be used to obtain early feedback on the requirements needed in the actually product or service when it is built.   This can be an actually 2D or 3D physically model of the product, or a storyboard which can be used for describing a less tangible product such as a computer program or a film, for example.

Once the requirements have been collected, analyzed, prioritized and decided upon, they are put forth in documentation which is described in the next post, the outputs of the Collect Requirements process.

Filed under: Uncategorized | Leave a comment »

In the last post, part 1 on the Tools and Techniques used in process 5.2 Collect Requirements, I showed a list of the various categories of requirements that need to be collected and indicated where each of those categories come from.

In this post, I will now start going into the tools & techniques used to analyze, prioritize, and finally to decide upon what the requirements are for the project.

The first list of tools & techniques are what I would call “generic” tools & techniques for any major decision-making process on a project, whether it be deciding upon requirements (as in this process), deciding upon any changes to be made in the project (part of process 4.6 Integrated Change Control), or frankly any of the preliminary planning processes that deal with the major constraints of the project (process 6.1 Plan Schedule Management, process 7.1 Plan Cost Management, etc.).

5.2.2 Collect Requirements:  Tools & Techniques

5.2.2.1  Expert Judgement

A list of the various types of experts you may want to consult regarding the requirements is found in the PMBOK® Guide, but the experts you need will be based on what category of requirements you are talking about (see previous post for those categories):   technical experts will be needed for solution requirements, the project sponsor and/or upper management for business requirements, etc.

5.2.2.2 Data Gathering

• Brainstorming–this is a meeting held with team members and selected experts to generate and collect multiple ideas related to the project and product requirements.
• Interviews–these are interviews held stakeholders such as subject matter experts (for the solution requirements), sponsors or other executives (for the high-level and/or business requirements), and PMs with experience on other relevant projects (for project requirements).
• Focus groups–these are group meetings with stakeholders to discuss their expectations and attitudes about a proposed product, service, or result.
• Questionnaires and surveys–these are written sets of questions sent out to various respondents, whether they are subject matter experts, stakeholders, or experienced PMs.   Questionnaires and surveys are easier to manage and facilitate than focus groups, and are used when quick turnaround is needed, and/or the respondents are geographically dispersed, making in-person interviews or focus groups less practical.
• Benchmarking–like a focus group, but with the discussion centering around a comparison between the proposed product and those of competitive organizations.

5.2.2.3  Data Analysis

Besides gathering data on potential requirements, you need a way to analyze those requirements once they are proposed.   There is a complete list of documents that can be used to make such an analysis regarding requirements in the PMBOK® Guide, but these would include the following:

Business plans (for business requirements)

Agreements, Problem/issue logs, Requests for proposal, Use cases (for solution requirements)

Business process or interface documentation, Business rules repositories, Current process flows, Policies and procedures (for project requirements)

Marketing literature, Use Cases (for Transition and readiness requirements)

Regulatory documentation (for quality requirements)

5.2.2.4  Decision Making

This applies to any decision-making process in a project, not just those decisions having to do with requirements.

• Multicriteria decision analysis– this provides a systematic approach to evaluate and rank many ideas.

Once the analysis is complete, then it is time to make a decision.   This can be done either through autocratic decision making, where one individual takes responsibility for making the decision for the group, or some sort of system of voting as a group, which may include the following decision-making techniques:

• Unanimity–everyone must agree on a single course of action in order for it to go forward.
• Majority–more than 50% of the members have to support a single course of action in order for it to go forward.
• Plurality–the largest block of votes in a group decides on a single course of action in order for it to go forward.

The next post will cover those techniques which can help make a decision regarding requirements, including data representation techniques (affinity diagrams, mind mapping), interpersonal and team skills (nominal group techniques, observation/conversation, facilitation), context diagrams, and prototypes.

Filed under: Uncategorized | Leave a comment »