Webinar Slides - Boston Chapter of the IIBA
Webinar Slides - Boston Chapter of the IIBA
Taking the Driver’s Seat
April 18, 2013
Why do we need to prioritize?
How to Liaise with Your Project Manager
In the Driver’s Seat
Open Discussion and Q&A
Introduction and Ground Rules
• Who is our instructor?
• What can we expect tonight?
• Web Session Format
• Technology vs. Productivity
• Respect Time and Perspectives
of Fellow Participants
• Quiz and Activities
• Use the Parking Lot
• Interact: Questions are
• Reach out offline
• Earn Professional
Development Credit (PMI)
• Have fun!
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?
Section 1.3.3 – A requirement is:
1. A condition or capability needed by a
stakeholder to solve a problem or achieve an
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).
Requirements: “I want it all!!!”
• Project Managers have
a lot to focus on…
• Throughout the project
lifecycle, PMs are
• BAs are the custodians
• PMs and BAs control
(not stifle) change
Requirements in the Lifecycle
• Predictive vs. Adaptive Project Lifecycle
• What if Requirements Change?
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
“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
Activity – 2 minutes
• It is 2p.m. on a Saturday. You have 4 hours – you want to
accomplish the following (driving your spouse’s/friend’s car):
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
Repair chipped windshield
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
• Which items do you choose?
What Drove Your Decisions?
Personal Value of the Item?
The Risk Factor? Assumptions?
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?
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
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.
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
• 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
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
• 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
• 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.
Tools and Techniques
• Decision Analysis
▫ Decision Flow
▫ Decision Tree
▫ Weighted Scorecards
Ranking and Categorization
Past Project Templates (i.e. RTM)
Observations (Job Shadowing)
Surveys / Questionnaires
Context Diagrams (swim-lanes
• Document Analysis
Tools and Techniques (Examples)
What category is
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
The RP Process
How to Liaise with Your Project
▫ Drive RP Workshops
▫ Take initiative to
interact with PM for
▫ Manage requirement
▫ Monitor the RTM
▫ Verify alignment to use
case and test scripts
• Use your PM wisely!
• Coach the PM about
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?”
You are in the Driver’s Seat
• What can you do to drive
the prioritization process?
• Who really owns
• Who owns validation of
• Who owns delivery of
• When can priorities
Objectives – Requirements Validation
• Did we achieve all of our objectives?
• Which objectives were of particular interest
• Which objectives were not met in the way we
• Which objectives were a lower priority to
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.
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
*PDU code available by email