4squareviews

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 »

When I sat down to do this post, I realized that a) this process is so crucial to the success of a project and b) there are so many tools & techniques in this process , that I can’t do it justice in one post.   I am going to start with an introduction to the different types of requirements.

Types of requirements

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).

Now that we have categorized what requirements may be considered, the next post will start to go through the tools & techniques that will collect, organize, prioritize, and finally select the requirements that will form the shape of the scope of the product and the project itself.

Filed under: Uncategorized | Leave a comment »

The first process in the Scope knowledge area, Plan Scope Management, was essentially a place where all the other processes for scope management were detailed, including this first one, Collect Requirements.

The requirements are the conditions or capabilities that the product, which is being produced as a result of the project, are supposed to contain.    These requirements are  the scope of the product; it is distinguished from the scope of the project, which is the work required during the project to produce that product as an end result.

Where do these requirements come from?   They can be specified in the project charter (see 5.2.1.1 below), they can come from business documents like the business case (see 5.2.1.4 below), from agreements (contracts) with vendors or business partners (see 5.2.1.5 below), or from stakeholders.   This post will cover these various inputs into the process of collecting and analyzing these various potential requirements,

5.2.1  Collect Requirements:  Inputs

5.2.1.1 Project Charter

The project charter is the output of process 4.1 Create Project Charter.   The project charter is essentially the “seed” of the project, because it contains a lot of high-level information on the project including any high-level requirements the sponsor wants to include as part of that charter.   This is probably the first place to look for such requirements if you are a project manager.

5.2.1.2  Project Management Plan

The components of the project management plan that are used as inputs for this process are:

• Scope Management Plan–this is the output of process 5.1 Plan Scope Management.   In particular, the scope management plan will show how this process, 5.2 Collect Requirements, needs to be done.
• Requirements Management Plan–the Project Management Plan contains management plans from each knowledge area, like the Scope Management Plan mentioned above, and it also contains some supplemental management plans like this one designed specifically on how to handle requirements.   Given that the subject of this process is requirements, it is easy to see why this management plan is an input.   It is also an output of process 5.1 Plan Scope Management
• Stakeholder Engagement Plan–this is an output of process 13.2 Plan Stakeholder Engagement.    You will need to get many of the requirements from stakeholders to supplement the ones you find in the project charter and the business case, and the Stakeholder Engagement Plan will give you information on who the stakeholders are and what their current level of engagement is with respect to the project.

5.2.1.3 Project Documents

Here are some project documents which may be considered as inputs for this process.

• Assumption log–high-level strategic and operational assumptions and constraints are normally identified in the business case (see 5.2.1.4 below) and will flow into the project charter (see 5.2.1.1 above).   These high-level assumptions are then put into the assumption log, which will later also include lower-level assumptions such as technical specifications, budget and schedule estimates, risks, etc. that will be developed later on in the planning process.
• Lessons learned register–(output of process 4.4 Manage Project Knowledge)the specific area that this register can provide information on is techniques for effective collection of requirements, particularly for projects that are using iterative or adaptive (agile) product development methodology that develop the scope on a cyclical or ongoing periodic basis.
• Stakeholder register–(output of 13.1 Identify Stakeholders) contains information on stakeholders so you can identify those who can provide information on the requirements.   It also contains information on the stakeholder’s expectations and level of engagement with the project which will help you when engaging them regarding these requirements.

5.2.1.4  Business Documents

In particular, the business case, which ties together the a) purpose or objective of the project, b) the business need for the project (why is the project being done, i.e., what need does it fulfill), and c) the strategic alignment of the project (how will it align with the business strategies of the organization doing the project).   This can be done by the sponsor or by a business analyst.

5.2.1.5 Agreements

Agreements with business partners can contain project and product requirements.    (There are also agreements with vendors, but these will enter the picture later on in the planning process.)

5.2.1.6  Enterprise Environmental Factors

Several of these are listed in the PMBOK Guide, but the most important are the organization’s culture, which will determine many requirements on how the project is done (the scope of the project), and marketplace conditions, which will determine many requirements of the product.

5.2.1.7 Organizational Process Assets

The OPAs that can influence the Collect Requirements process include:

• Policies and procedures–this will go into the Scope Management Plan which will outline the process by which the company will do the processes in the Scope knowledge area, including how requirements should be collected and analyzed, which is the subject of this particular process 5.2 Collect Requirements.
• Historical information and lessons learned repository from previous projects–this will contain information not only on how requirements were collected from previous projects, but will also inform the assumptions log which will be helpful in analyzing those requirements.

Now that you have the requirements you have collected from various sources–from the project charter, business case, stakeholders, and project documents such as the assumptions log and the lessons learned register, it is now time to analyze them.   That is the subject of the next post…

Filed under: Uncategorized | Leave a comment »

There are two outputs for this process:   the Scope Management Plan and the Requirements Management Plan.   These plans outline the all the other processes in the scope knowledge area.

5.1.3 Plan Scope Management:  Outputs

This plan shows how the scope will be defined and developed in the Executing process group, and how it will be monitored, controlled and validated in the Monitoring and Controlling process group.

The components of the scope management plan include:

• The process for preparing a project scope statement, as part of Process 5.3 Define Scope.
• The process for enabling the creation of the Work Breakdown Structure (WBS) from the project scope statement, as part of Process 5.4 Create WBS.
• The process for approving and maintaining the scope baseline, as parts of Process 5.6 Control Scope.
• The process for formally accepting the completed project deliverables as part of Process 5.5 Validate Scope.

5.1.4 Requirements Management Plan

This plan shows how the project requirements and the product requirements will be analyzed, documented and managed.    This is sometimes called the “Business Analysis Plan” when it is a document created by business analysts.

The components of the requirement plan include:

• The process of planning requirements activities
• The process of configuration management, which tracks changes made in the requirements during the course of the project.
• The process of prioritizing requirements
• Metrics used in the process of showing successful completion of requirements
• Traceability of requirements, so that team members can be identified to be responsible for certain requirements, and subject matter experts can be consulted when decisions have to made concerning those requirements.

All of these requirements are part of the Process 5.2 Collect Requirements.

As you can see from reviewing the above, essentially the output of this Process 5.1 are the guidelines of how to do the processes in all of the other Processes 5.2 through 5.6.

Next process is Process 5.2 Collect Requirements:  that is the subject of the next post.

Filed under: Uncategorized | Leave a comment »