requirements prioritization taking the driver’s seat april 18, 2013

Requirements PrioritizationTaking the Driver’s SeatApril 18, 2013

Why do we need to prioritize?

Agenda

•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?

• 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

•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?

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

Requirements: “I want it all!!!”

• 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

PMBOK & Requirements

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

Activity – 2 minutes

▫ 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

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

• You can’t do them all – how do you decide? What is your technique?

• Which items do you choose?

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?

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.

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

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

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)

• Observations (Job Shadowing)

• Prototypes• Surveys / Questionnaires• Benchmarking• Context Diagrams (swim-

lanes & ERDs)• Document Analysis

Tools and Techniques (Examples)

The RTM

What category is missing?

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

The RP Process

Rqts

Rqts

Ob

stacle

Aw

are

ness

How to Liaise with Your Project Manager

•Use your PM wisely!•Coach the PM about

preferred tools

▫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

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

prioritization?• Who owns validation of

requirements?• Who owns delivery of

requirements?• When can priorities

change?

Open Discussion and Q&A

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?

References

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.

1. PMI (2012), A Guide to the Project Management Body of Knowledge, 5th Ed.

2. IIBA (2009), A Guide to the Business Analysis Body of Knowledge, 2nd Ed.

3. Jake Markham, Requirements Prioritisation – IIBA July ’09

4. Microsoft Press – Karl E. Wiegers (2003), Software Requirements, 2nd Ed.

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

Benjamin T. Rebeske, MSPM, PMP

requirements prioritization taking the driver’s seat april 18, 2013

Documents