Requirements Prioritization: Taking the Driver's Seat

1. Requirements Prioritization Taking the Drivers Seat April 18, 2013

2. Why do we need to prioritize?

3. Agenda Introductions Objectives Requirements Prioritization Activity How to Liaise with Your Project Manager In the Drivers Seat Open Discussion and Q&A Wrap-up Page 3

4. 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! Page 4

5. 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? Page 5

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

7. Requirements: I want it all!!! Page 7

8. 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 Page 8

9. Requirements in the Lifecycle Predictive vs. Adaptive Project Lifecycle What if Requirements Change? Page 9

10. 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 doesnt give the project team much to work with. -Karl E. Wiegers Page 10

11. 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 spouses/friends car): You cant do them all how do you decide? What is your technique? Which items do you choose? Page 11

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

13. 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. Page 13

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

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

16. 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 Page 16

17. Tools and Techniques (Examples) Page 17

18. The RTM What category is missing? Page 18

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

20. The RP Process Rqts Rqts Obstacle Awareness Page 20

21. 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 Page 21

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

23. You are in the Drivers 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

24. Open Discussion and Q&A Page 24

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

26. 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 Page 26

27. Take the Drivers Seat! Benjamin T. Rebeske, MSPM, PMP 2013, All Rights Reserved RebeskeB@gmail.com *PDU code available by email