Requirements Prioritization
Taking the Driver’s Seat
April 18, 2013
Why do we need to prioritize?
Agenda
•
•
•
•
•
•
•
•
•
Page 3
Introductions
Objectives
Requirements
Prioritization
Activity
How to Liaise with Your Project Manager
In the Driver’s Seat
Open Discussion and Q&A
Wrap-up
Introduction and Ground Rules
• Who is our instructor?
• What can we expect tonight?
Page 4
• Web Session Format
• Technology vs. Productivity
• Respect Time and Perspectives
of Fellow Participants
• Quiz and Activities
• Use the Parking Lot
• Interact: Questions are
Encouraged
• Reach out offline
• Earn Professional
Development Credit (PMI)
• Have fun!
Objectives
•
•
•
•
•
Page 5
What are requirements?
How do they fit into a project lifecycle?
What is the expectation of the Business Analyst?
What is the expectation of the Project Manager?
How do I prioritize my requirements?
Requirements
Section 1.3.3 – A requirement is:
1. A condition or capability needed by a
stakeholder to solve a problem or achieve an
objective
2. A condition or capability that must be met or
possessed by a solution or solution component
to satisfy a contract, standard, specification, or
other formally imposed documents
3. A documented representation of a condition or
capability as in (1) or (2).
Page 6
Requirements: “I want it all!!!”
Page 7
PMBOK &
Requirements
• Project Managers have
a lot to focus on…
• Throughout the project
lifecycle, PMs are
facilitators of
requirements delivery
• BAs are the custodians
of requirement
alignment, selection,
prioritization, and
validation.
• PMs and BAs control
(not stifle) change
Page 8
Requirements in the Lifecycle
• Predictive vs. Adaptive Project Lifecycle
• What if Requirements Change?
Page 9
Requirements Prioritization (RP)
By the Book (BABOK):
The importance of requirements may be based on their relative value,
risk, difficulty of implementation, or on other criteria. These priorities
are used to determine which requirements should be targets for
further analysis and to determine which requirements should be
implemented first.
“Left to their own devices, stakeholders will set
85% of the requirements at high priority, 10% at
medium, and 5% at low priority. This doesn’t give
the project team much to work with.”
-Karl E. Wiegers
Page 10
Activity – 2 minutes
Scenario:
• It is 2p.m. on a Saturday. You have 4 hours – you want to
accomplish the following (driving your spouse’s/friend’s car):
▫
▫
▫
▫
▫
▫
▫
▫
▫
Grocery shopping
Soccer game for the kids
Purchase BDay gift for sister
Schedule baby sitter
Make reservations at
restaurant for 7 p.m. dinner
Get gas for the car
Wash the car
Weed the front yard
Pick up girl scout cookies for
delivery to buyers
▫
▫
▫
▫
▫
▫
▫
▫
▫
Pick up dry cleaning
Get dressed for formal dinner
Shower / personal grooming
Return defective merchandise
for refund
Repair chipped windshield
Eat lunch
Fold and iron clean laundry
Replace broken sunglasses
Mail Credit Card payment
• You can’t do them all – how do you decide? What is your
technique?
• Which items do you choose?
Page 11
What Drove Your Decisions?
•
•
•
•
•
•
Personal Value of the Item?
The Risk Factor? Assumptions?
Difficulty?
Likelihood of Getting it Done on Time?
Simply a “Must Have?”
How Closely Linked it was to other Items?
(Geography, type of task, etc.)
• Unspoken Agreement with the Spouse/Friend?
• Personal Deadline?
Page 12
BABOK: Basis for Prioritization
•
•
•
•
•
•
•
•
Business Value: This approach prioritizes requirements based on cost-benefit analysis of their
relative value to the organization. The most valuable requirements will be targeted for
development first. This approach is common when enhancing an existing solution that already
meets specified minimal requirements, or when delivering the solution incrementally.
Business or Technical Risk: This approach selects requirements that present the highest risk
of project failure. Those requirements are investigated and implemented first to ensure that if the
project fails it does so after as little expenditure as possible.
Implementation Difficulty: This approach selects requirements that are easiest to implement.
This approach is often selected during a pilot of a new development process or tools or when
rolling out a packaged solution, as it allows the project team to gain familiarity with those things
while working on lower-risk requirements.
Likelihood of Success: This approach focuses on the requirements that are likely to produce
quick and relatively certain successes. It is common when a project is controversial and early
signs of progress are needed to gain support for the initiative.
Regulatory or Policy Compliance: This approach prioritizes requirements that must be
implemented in order to meet regulatory or policy demands imposed on the organization, which
may take precedence over other stakeholder interests.
Relationship to Other Requirements: A requirement may not be high value in and of itself,
but may support other high-priority requirements and as such may be a candidate for early
implementation.
Stakeholder Agreement: This approach requires the stakeholders to reach a consensus on
which requirements are most useful or valuable. It is often used in combination with one or more
of the other approaches described above.
Page 13
Urgency: This approach prioritizes requirements based on time sensitivity.
Inputs to RP
• Business Case: The business case states the key goals and
measures of success for a project or organization, and priorities
should be aligned with those goals and objectives.
• Business Need: Serves as an alternative to the business case if no
business case has been defined.
• Requirements: Any requirement may be prioritized, at any point
in its lifecycle. Requirements prioritization requires that
requirements have been stated by stakeholders; however, the
requirements may not have been fully analyzed or in their final
form.
• Requirements Management Plan: Defines the process that will
be used to prioritize requirements.
• Stakeholder List, Roles, and Responsibilities: The list of
stakeholders, annotated with their levels of authority and influence,
is used to determine which stakeholders need to participate in
prioritization.
Page 14
Challenges
Challenges in facilitating a requirements prioritization session include:
• Non-negotiable Demands: Stakeholders attempt to avoid difficult
choices, fail to recognize the necessity for making tradeoffs, or desire to
rank all requirements as high priority.
• Unrealistic Tradeoffs: The solution development team may intentionally
or unintentionally try to influence the result of the prioritization process by
overestimating the difficulty or complexity of implementing certain
requirements.
• Too Many Stakeholders: It is not uncommon that many business area
resources demand to be in attendance at RP workshops (or even RD
workshops). The larger groups can be harder to coordinate and individual
agendas may not align with overall business objectives or future state
processes.
• Poor Preparation: The BA may face scheduling, participation, and tool /
approach challenges in the RP session without proper preparation of
facilities, tools to be used, a focused approach and agenda, pre-organized
RP inputs, and clear delineation of ground rules for participants.
Page 15
Tools and Techniques
• Decision Analysis
▫ Decision Flow
▫ Decision Tree
▫ Weighted Scorecards
•
•
•
•
•
•
•
•
Risk Analysis
MoSCoW
Time Boxing/Budgeting
Voting
Delphi Technique
Brainstorming
Ranking and Categorization
Past Project Templates (i.e. RTM)
Page 16
•
•
•
•
•
Observations (Job Shadowing)
Prototypes
Surveys / Questionnaires
Benchmarking
Context Diagrams (swim-lanes
& ERDs)
• Document Analysis
Tools and Techniques (Examples)
Page 17
The RTM
What category is
missing?
Page 18
Output
Requirements [Prioritized]: A prioritized
requirement has an attribute that describes its
relative importance to stakeholders and the
organization. At the completion of this task, each
requirement should have an assigned priority. The
priorities may apply to a requirement or to a
group or related requirements
Page 19
The RP Process
Page 20
Obstacle Awareness
Rqts
Rqts
How to Liaise with Your Project
Manager
▫ Drive RP Workshops
▫ Take initiative to
interact with PM for
validation
▫ Manage requirement
change
▫ Negotiate
communication and
status frequency
▫ Monitor the RTM
▫ Verify alignment to use
case and test scripts
Page 21
• Use your PM wisely!
• Coach the PM about
preferred tools
Pop Quiz! Acronyms…
•
•
•
•
•
What is the “RTM?”
What does “MoSCoW” stand for?
What is a “BOK?”
What would I do with an “ERD?”
Why do people keep calling me a “SME?”
Page 22
You are in the Driver’s Seat
• What can you do to drive
the prioritization process?
• Who really owns
prioritization?
• Who owns validation of
requirements?
• Who owns delivery of
requirements?
• When can priorities
change?
Page 23
Page 24
Objectives – Requirements Validation
• Did we achieve all of our objectives?
• Which objectives were of particular interest
to me?
• Which objectives were not met in the way we
imagined?
• Which objectives were a lower priority to
me?
Page 25
References
Benjamin T. Rebeske, MSPM, PMP
A PMP since 2005 and a PMI member
since 2002, Benjamin has been an
emphatic and passionate proponent of the
Project Management profession within the
Utility and Information Technology
Industries. Holding a Masters of Science
in Project Management (MSPM) from
George Washington University (2005), and
certifications as a risk manager and scheduling professional,
Benjamin brings over 14 years of real-world experience in
project delivery, peer mentoring, PMI student training, and
contract and requirements management. He partners with
leading minds in the industry to bring visionary ways to
promote and implement mature Project methodologies and
has worked with diverse and global firms such as Microsoft,
ORACLE and HCL. Currently with the Ernst & Young
Advisory consulting team here in Boston, he now focuses on
building relationships which promote excellence in Project
Management and which foster strong relationships with our
partners, clients, and industry professional alliances.
Finally, in the realm of requirements and requirement
traceability, Benjamin has led four large-scale enterprise
transformation projects and brought cross functional ideas
and business process change to life even in the face of the
most diverse and resistant work cultures.
Page 26
1.
2.
3.
4.
PMI (2012), A Guide to the Project
Management Body of Knowledge, 5th Ed.
IIBA (2009), A Guide to the Business
Analysis Body of Knowledge, 2nd Ed.
Jake Markham, Requirements
Prioritisation – IIBA July ’09
Microsoft Press – Karl E. Wiegers
(2003), Software Requirements, 2nd Ed.
Take the Driver’s Seat!
Benjamin T. Rebeske, MSPM, PMP
© 2013, All Rights Reserved
RebeskeB@gmail.com
*PDU code available by email