Friday, May 23, 2014

Project Scope Management - Collect Requirements

When you collect requirements you have to determine what requirements are to be documented as well as managing the stakeholder needs and requirements to meet the project objectives. Requirements become the foundation of the WBS, cost, schedule and quality planning. You start with the analysis of the information found in the project charter, stakeholder register and stakeholder management plan. You can group requirements into different classifications and allow for further refinement. These groups can include the following:
  • Business requirements - describing the higher level needs of the organization
  • Stakeholder requirements - describes the needs of the stakeholder
  • Solution requirements - describes features, functions and characteristics of the product, service or result that will meet the requirements. They can be functional (describes the behaviors of the product) and nonfunctional requirements (describes the environmental conditions).
  • Transition requirements - describes the temporary capabilities (data conversion or training)
  • Project requirements - describes the actions, processes, or other conditions the project needs
  • Quality requirements - the criteria needed to validate the successful completion of the project deliverable 

Now let's take a look at Inputs, Tools and Techniques, and Outputs of this process: 


1) Scope Management Plan

  • This provides clarity as to how the project teams will determine which type of requirements need to be collected for the project.
2) Requirements Management Plan
  • Provides the processes that will be used throughout the Collect Requirements process to define and document the stakeholder needs

3) Stakeholder Management Plan
  • Is used to understand the stakeholder communication requirements and their level of engagement through out the project
4) Project Charter
  • Provides a high-level description of the product, service, or result of the project so the detail requirements can be developed
5) Stakeholder register
  • Used to identify stakeholders who can provide information on the requirements you are gathering.
  • Captures the major requirements and main expectations of the stakeholders
6) Interviews
  • Meeting with a stakeholder on a 1:1 basis is important to gather specific information about the requirements and recording their responses. Because you are meeting with them in private you can also obtain confidential information.
7) Focus Groups
  • Bringing together a group of prequalified stakeholders will provide a more conversational forum to gather information about expectations and attitudes about the proposed product, service or result.
8) Facilitated Workshops
  • Focused session to bring the key stakeholders together to define product requirements. They help define cross-functional requirements and reconcile stakeholder differences. By discovering issues early on you can resolve them quickly. Types of facilitated workshops are:
    • Joint Application Design/Development (JAD) - used in the software development industry by bringing subject matter experts and the development team together to improve the software development process
    • Quality Functional Deployment (QFD) - used in the manufacturing industry to help determine critical characteristics for new product development by collecting customer needs also know as voice of the customer (VOC).
  • User stories are short, textual descriptions of required functionality. (used in agile methods)
9) Group Creativity Techniques
  • Group activities to identify project and product requirements may include:
    • Brainstorming - collection of multiple ideas
    • Nominal group technique - a voting process to rank the brainstormed ideas
    • Idea/mind mapping - ideas consolidated into a single map to reflect commonality and differences in understanding, and generate new ideas
    • Affinity diagram - allows large number of ideas to be classified into groups for review and analysis
    • Multicriteria decision analysis - utilizes a decision matrix to provide a systematic analytical approach to establish criteria (risk levels, valuation, evaluate, rank ideas)
10) Group Decision-Making Techniques
  • Assessment process that has multiple alternatives with an expected outcomes for future actions. They can help generate, classify, and prioritize product requirements. Some of these techniques may include:
    • Unanimity - where everyone agrees on a single course of action
      • Delphi technique - questionnaires are given to a selected group and only the facilitator can see them all to maintain anonymity
    • Majority - a decision is made based on 50% or more of the members
    • Plurality - when you have more than two options the one with the most votes wins even when its not more than 50% of the votes
    • Dictatorship - one individual makes the decision for the group
11) Questionnaires and Surveys
  • Written set of questions given to a large group of people, maybe spread out geographically, to gather feedback quickly.
12) Observations
  • By doing an observation or shadowing a person in their environment you can observe and document the processes they carry out.
13) Prototypes
  • When you can get early feedback on requirement you can create a working model of the expected product before actually building it. It allows stakeholders to experiment with the model and gather more feedback to continue with development.
    • Storyboarding - technique showing sequence or navigation through a series of images or illustrations
14) Benchmarking
  • Comparing practices, processes and operations with a comparable organization to identify best practices, generate ideas, and provide a basis for measurement
15) Context Diagrams
  • A diagram that shows the business system and how people or other systems interact with it. Look at the sample below so you can see the visual representation of the process and who does what. 















Source: Murat Akdeniz

16) Document Analysis
  • When you analyze existing documents and identify the important information relevant to the requirements and use them to elicit requirements. (Business plans, marketing literature, agreements, use cases, issue logs, procedures etc. )
17) Requirements Documentation
  • Documentation that describes how individual requirements meets the business need. Before being baselined they need to be unambiguous (measurable and testable), traceable, complete, consistent, and accepted by stakeholders. Some of these documentation may include:
    • Business requirements
      • Objectives for traceability
      • Business rules
      • Guiding principles
    • Stakeholder requirements
      • Impacts to other organizational areas
      • Impacts to other entities inside or outside the organization
      • Stakeholder communication and reporting requirements
    • Solution requirements
      • Functional and nonfunctional
      • Technology and standard compliance
      • Support and training
      • Quality
      • Reporting requirements
    • Project requirements
      • Levels of service, performance, safety, compliance etc.
      • Acceptance criteria
    • transition requirements
    • Requirements assumptions, dependencies and constraints.
18) Requirements Traceability Matrix
  • A grid that links product requirements from their origin to the deliverables that satisfy them. You can track the requirements throughout the project life cycle and provide a structure for managing changes to the product scope. Check out the columns in the below example from the PMBOK 5th ed. so you can see the column labels as to what is tracked.















Source: PMBOK 5th ed. 


























No comments:

Post a Comment