View
218
Download
2
Category
Tags:
Preview:
Citation preview
Project ManagementScope Management & Requirements
Minder Chen, Ph.D.CSU Channel Islands
Minder.chen@csuci.edu
PM: Requirements - 2 © Minder Chen, 2012
Design Thinking
http://blogs.sap.com/cloud/2011/04/19/co-innovation-2-0-at-sap-design-thinking-and-a-user-centric-approach-to-meet-customer-needs/
PM: Requirements - 3 © Minder Chen, 2012
Elicit Requirements
Expand stakeholder list for solution.
Problem Analysis Roadmap
Choose the best solution(s) to meet the goals.
Best solution identified
Problem validated/adjusted
Business problem defined Actual problem identifiedand defined
Identify stakeholders for problem. Root cause analysis.
Reassess that the solution idea is the best solution.
Understand the problem in the context of the business goals.
Business Problem
Solution idea or
Opportunity
PM: Requirements - 4 © Minder Chen, 2012
Root Causes: What Are the Problems Behind the Problem?
Fishbone Diagram Techniques
List contributing causes to the identified problem.Keep asking “Why?” (expand each rib).
The perceived business problem.
No Banking at night
Too much waiting
Want Privacy
when banking
Customers are dissatisfied
with our service.
Bankin
g in
airpo
rts
Wan
t mor
e ba
nking
loca
tions
Queue
s in
the
bran
ches
are
too
long
PM: Requirements - 5 © Minder Chen, 2012
Gain Agreement on the Problem Definition
Problem Statement
Vision
The problem of (describe the problem)
affects (the stakeholders affected by the problem)
the impact of which is
(what is the impact of the problem)
a successful solution would
(list some key business benefits of a successful solution)
PM: Requirements - 6 © Minder Chen, 2012
Project Scope Management
5.1 Plan Scope Management—The process of creating a scope management plan that documents how the project scope will be defined, validated, and controlled.
5.2 Collect Requirements—The process of determining, documenting, and managing stakeholder needs and requirements to meet project objectives.
5.3 Define Scope—The process of developing a detailed description of the project and product.
5.4 Create WBS—The process of subdividing project deliverables and project work into smaller, more manageable components.
5.5 Validate Scope—The process of formalizing acceptance of the completed project deliverables.
5.6 Control Scope—The process of monitoring the status of the project and product scope and managing changes to the scope baseline.
PM: Requirements - 7 © Minder Chen, 2012
Product Scope vs. Project Scope
In the project context, the term scope can refer to:
•Product scope. The features and functions that characterize a product, service, or result; and/or
•Project scope. The work performed to deliver a product, service, or result with the specified features and functions. The term project scope is sometimes viewed as including product scope.
PM: Requirements - 8 © Minder Chen, 2012
Plan Scope Management Data Flow Diagram
PM: Requirements - 9 © Minder Chen, 2012
Collect Requirements: Inputs, Tools & Techniques, and Outputs
PM: Requirements - 10 © Minder Chen, 2012
Collect Requirements Data Flow Diagram
PM: Requirements - 11 © Minder Chen, 2012
What Are Sources for Requirements?
Analyst
Customer
Problem Domain
Users
Partners
Site Visits Domain Experts
Industry AnalystsCompetitive info
Initial RequestsBug ReportsChange Requests
Requirement SpecsBusiness Models
Business PlansPersonal Goals
PM: Requirements - 12 © Minder Chen, 2012
Challenges in Requirements Elicitation
PM: Requirements - 13 © Minder Chen, 2012
Challenges in Requirements Elicitation
http://www.whattofix.com/blog/archives/2008/05/peace-for-pachy.php
PM: Requirements - 14 © Minder Chen, 2012
http://www.businessballs.com/treeswing.htmCheck this out http://www.businessballs.com/businessballs_treeswing_pictures.htm
PM: Requirements - 15 © Minder Chen, 2012
What Problems Might Be Encountered?• Stakeholders
– Have a pre-conceived idea of the solution.– Do not know what they really want.– Are unable to articulate what they want.– Think they know what they want, but do not
recognize it when it is delivered.• Analysts
– Think they understand user problems better than users.
• Everybody – Everyone sees things from
their own point of view.– Believes everyone is
politically motivated. Stakeholder Analyst
??
PM: Requirements - 16 © Minder Chen, 2012
Laundry List
16
Prioritizing MUST have vs. NICE to have Clarification Attack ambiguity because ambiguity costs!Operational definition Measurable and testable;
PM: Requirements - 17 © Minder Chen, 2012
Costs of Errors in Lifecycle Phases
http://secretsofconsulting.blogspot.com/2014/11/ambiguity-in-stating-requirements.html
PM: Requirements - 18 © Minder Chen, 2012
Interview Techniques
PM: Requirements - 19 © Minder Chen, 2012
Project Management Plan Baseline
• Once the project management plan is baselined, it may only be changed when a change request is generated and approved through the Perform Integrated Change Control process.
• Project baselines include, but are not limited to:
– Schedule baseline,
– Cost performance baseline, and
– Scope baseline.
PM: Requirements - 20 © Minder Chen, 2012
Requirements BaselineThe set of features that constitutes the agreed upon basis for development and that can only be changed through a formal procedure.
Establish Requirements Baseline
How do we know what the needs are?How do we determine priority?Where do we set the baseline?
• Feature 1: The system must...• Feature 2: The system must...• Feature n: The system must...
TimeProject Start Date
TargetRelease Date
PM: Requirements - 21 © Minder Chen, 2012
System to build
Needs
SoftwareRequirements
DesignTest User
Doc
Capture
Features
Trac
eabi
lity
ProblemSpace
Development TeamUser/Customer
Scope Management
ProblemProblem
PM: Requirements - 22 © Minder Chen, 2012
Project Scope Statement• Product scope description. Progressively elaborates the
characteristics of the product, service, or result described in the project charter and requirements documentation.
• Product acceptance criteria. Defines the process and criteria for accepting completed products, services, or results.
• Project deliverables. Deliverables include both the outputs that comprise the product or service of the project, as well as ancillary results, such as project management reports and documentation. The deliverables may be described at a summary level or in great detail.
• Project exclusions. Generally identifies what is excluded as from the project. Explicitly stating what is out of scope for the project helps to manage stakeholders’ expectations.
• Project constraints.
PM: Requirements - 23 © Minder Chen, 2012
Classifications of Requirements• Business requirements, which describe the higher-level
needs of the organization as a whole, such as the business issues or opportunities, and reasons why a project has been undertaken.
• Stakeholder requirements, which describe needs of a stakeholder or stakeholder group.
• Solution requirements, which describe features, functions, & characteristics of the product, service, or result that will meet the business & stakeholder requirements.
– Functional requirements describe the behaviors of the product. Examples include processes, data, and interactions with the product.
– Nonfunctional requirements supplement functional requirements and describe the environmental conditions or qualities required for the product to be effective. Examples include: reliability, security, performance, safety, level of service, supportability, retention/purge, etc.
PM: Requirements - 24 © Minder Chen, 2012
Classifications of Requirements
• Transition requirements describe temporary capabilities, such as data conversion and training requirements, needed to transition from the current “as-is” state to the future “to-be” state.
• Project requirements, which describe the actions, processes, or other conditions the project needs to meet.
• Quality requirements, which capture any condition or criteria needed to validate the successful completion of a project deliverable or fulfillment of other project requirements.
PM: Requirements - 25 © Minder Chen, 2012
Group Creativity Techniques• Brainstorming. A technique used to generate and collect multiple ideas
related to project and product requirements. Although brainstorming by itself does not include voting or prioritization, it is often used with other group creativity techniques that do.
• Nominal group technique. A technique that enhances brainstorming with a voting process used to rank the most useful ideas for further brainstorming or for prioritization.
• Idea/mind mapping. A technique in which ideas created through individual brainstorming sessions are consolidated into a single map to reflect commonality and differences in understanding, and generate new ideas.
• Affinity diagram. A technique that allows large numbers of ideas to be classified into groups for review
• and analysis.
• Multicriteria decision analysis. A technique that utilizes a decision matrix to provide a systematic analytical approach for establishing criteria, such as risk levels, uncertainty, and valuation, to evaluate and rank many ideas.
PM: Requirements - 26 © Minder Chen, 2012
Divergent and Convergent Thinking
http://chriscorrigan.com/parkinglot/?p=1265
PM: Requirements - 27 © Minder Chen, 2012
The Groan Zone
• Generating new ideas can be– Time-consuming
– Painful
• So why bother??!– Better solutions with diversity of opinions
– Help participants understand» Complexities
» Trade-offs
» Constraints
PM: Requirements - 28 © Minder Chen, 2012
Group Problem Solving Process
• Gather ideas for stakeholder requests/needs.
• Clarify and organize the ideas.
• Condense ideas.
• Prioritize remaining ideas.
PM: Requirements - 29 © Minder Chen, 2012
Brainstorming
• Generates as many ideas as possible.
Rules for Brainstorming Clearly state the objective of the
session. Generate as many ideas as
possible. Let your imagination soar. Do not allow criticism or debate. Combine ideas.
PM: Requirements - 30 © Minder Chen, 2012
Brainstorming Advantages and Disadvantages
• Advantages– Used anytime, anywhere.
– Good for groups.
– Good for high-level entities and assumptions.
– Amenable to some automation.
• Disadvantages– Susceptible to group processes.
– Unsystematic in “classic” form.
Takeda et al. 1993
PM: Requirements - 31 © Minder Chen, 2012
Idea Reduction: Prune and Organize
http://www.leanyourcompany.com/methods/Using-Affinity-Diagrams.asp
PM: Requirements - 32 © Minder Chen, 2012
Idea Reduction: Prioritize Ideas
• Prioritize remaining ideas.– Vote
» Cumulative votes• Buy ideas
» Single vote
– Apply evaluation criteria» Non-weighted
» Weighted
Rational University “bucks”
PM: Requirements - 33 © Minder Chen, 2012
Requirement Traceability Matrix
PM: Requirements - 34 © Minder Chen, 2012
Define Scope
Define Scope is the process of developing a detailed description of the project and product. The key benefit of this process is that it describes the project, service, or result boundaries by defining which of the requirements collected will be included in and excluded from the project scope.
PM: Requirements - 35 © Minder Chen, 2012
Define Scope
PM: Requirements - 36 © Minder Chen, 2012
Define Project Scope• Since all of the requirements identified in Collect Requirements may not
be included in the project, the Define Scope process selects the final project requirements from the requirements documentation delivered during the Collect Requirements process. It then develops a detailed description of the project and product, service, or result.
• The preparation of a detailed project scope statement is critical to project success and builds upon the major deliverables, assumptions, and constraints that are documented during project initiation. During project planning, the project scope is defined and described with greater specificity as more information about the project is known.
• Existing risks, assumptions, and constraints are analyzed for completeness and added or updated as necessary.
• The Define Scope process can be highly iterative. In iterative life cycle projects, a high-level vision will be developed for the overall project, but the detailed scope is determined one iteration at a time and the detailed planning for the next iteration is carried out as work progresses on the current project scope and deliverables.
PM: Requirements - 37 © Minder Chen, 2012
PM: Requirements - 38 © Minder Chen, 2012
Decomposition and The Work Package
• Decomposition is a technique used for dividing and subdividing the project scope and project deliverables into smaller, more manageable parts.
• The work package is the work defined at the lowest level of the WBS for which cost and duration can be estimated and managed.
• The level of decomposition is often guided by the degree of control needed to effectively manage the project.
• The level of detail for work packages will vary with the size and complexity of the project.
PM: Requirements - 39 © Minder Chen, 2012
Decomposition
• Identifying and analyzing the deliverables and related work;
• Structuring and organizing the WBS;
• Decomposing the upper WBS levels into lower-level detailed components;
• Developing and assigning identification codes to the WBS components; and
• Verifying that the degree of decomposition of the deliverables is appropriate.
PM: Requirements - 40 © Minder Chen, 2012
Sample WBS Decomposed Down Through Work Package
PM: Requirements - 41 © Minder Chen, 2012
Sample WBS Organized by Phase
PM: Requirements - 42 © Minder Chen, 2012
Sample WBS with Major Deliverables
PM: Requirements - 43 © Minder Chen, 2012
WBSThe WBS is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. Each descending level of the WBS represents an increasingly detailed definition of the project work. The WBS is finalized by assigning each work package to a control account and establishing a unique identifier for that work package from a code of accounts. These identifiers provide a structure for hierarchical summation of costs, schedule, and resource information. A control account is a management control point where scope, budget, actual cost, and schedule are integrated and compared to the earned value for performance measurement. Control accounts are placed at selected management points in the WBS. Each control account may include one or more work packages, but each of the work packages should be associated with only one control account. A control account may include one or more planning packages. A planning package is a work breakdown structure component below the control account with known work content but without detailed schedule activities.
PM: Requirements - 44 © Minder Chen, 2012
WBS Dictionary
• Code of account identifier,
• Description of work,
• Assumptions and constraints,
• Responsible organization,
• Schedule milestones,
• Associated schedule activities,
• Resources required,
• Cost estimates,
• Quality requirements,
• Acceptance criteria,
• Technical references, and
• Agreement information.
PM: Requirements - 45 © Minder Chen, 2012
Scope Management Tension• Scope management is maintaining a “healthy tension”
between what the customer wants (maximum features) and what development believes it can deliver in a fixed timeframe.
• It is essential for the developer to get agreement from the customer regarding a baseline set of features to develop for the system to be built.
• A good way to achieve the balance between customer desires and developer resources is by using iterative development and providing incremental “slices of the pie.” Then, the priorities can be reassessed at the end of each iteration.
• The ideal time to decide what the baseline set of features we will actually develop is after the system is defined and before we have put a lot of time into refining the details.
PM: Requirements - 46 © Minder Chen, 2012
Avoiding Scope Creep, But Allowing Change• ‘Real’ requirements: Identify what is really needed (not want)
to achieve business objectives.
• Minimum requirements: A conscious practice of a minimum requirements strategy, no ‘gold plating’, no including what ‘might be needed.
• All requirements should be recorded and identified by source.
• Realize all requirements have a cost and schedule impact.
• The use of an agreed negotiation and sanctioning process (it need not be heavyweight).
• All requirements come (in the end) through a well-identified channel, not from various and sundry random sources.
• Expectation management and communication with the customer about what will be in each iteration (via prototyping and iterative development). This helps uncover hidden requirements, unknown to the naïve developer but assumed by the domain-experienced customer.
PM: Requirements - 47 © Minder Chen, 2012
Uses for Requirement Attributes
Attributes link project elements
= Filter
FEAT 10 Approved Low High
FEAT 13 Proposed Medium Low
FEAT 40 Approved High High
$$$
$$
$
Cost Effo
rtRisk
StatusPrio
rity
PM: Requirements - 48 © Minder Chen, 2012
Process Helps Manage Scope
Scope management and change management are inextricably linked.
Customer andUser inputs
Marketing
New Feature
NewRequirement
BugApprovedDecisionProcess
(CCB: Change Control Board)
Single Channel for Approval
ChangeRequest (CR)
Reqt
Design
Code
Test
Maint
Help DeskUser inputs
Coders inputsTesters inputs
PM: Requirements - 49 © Minder Chen, 2012
Manage Expectations
• Why manage expectations?– So customers understand why you are
deferring functionality
– People perceive things differently
– Things happen
Gause & Weinberg, 1989
A new car!A new
car!
PM: Requirements - 50 © Minder Chen, 2012
How to Manage Expectations
• Understand customer expectations.
• Limit the expectations as appropriate.
• Include the source of the limitation.
• Under-promise and over-deliver.
Keep the possibilities open.
PM: Requirements - 51 © Minder Chen, 2012
Fisher, Ury, Getting to Yes, 1991
Improve your skills at every opportunity.
Improve Your Negotiation Skills
• Start negotiations with high demands, but don’t be unreasonable.
• Separate the people from the problem.
• Focus on interests, not positions.
• Understand your Best Alternative To a Negotiated Arrangement (BATNA) – Bottom line.
• Invent options for mutual gain (win-win).
• Use diplomacy.
PM: Requirements - 52 © Minder Chen, 2012
The Product Champion
• Prevents projects from drifting into a technical or political abyss.
• Helps manage project scope.• Owns the product vision.• Advocates for the product.• Defends against feature creep.• Negotiates with management, users, and
developers.• Maintains a balance between customer needs
and what can be delivered on time.• Represents the official channel between the
customer and the development team.
Recommended