SkarpChapter 20 of 21
Prioritization, Decision Modeling, and Solution Evaluation
When you can’t build everything, you must decide what matters most—learn how to prioritize requirements, model decisions, and evaluate whether solutions actually delivered value.
Why Prioritization and Evaluation Matter for CAPM Projects
The Real Constraint
Projects rarely have enough time, budget, or people to build every requested feature. You must help decide what to do first, what to delay, and how to prove the solution worked.
Three Skill Sets
This module links three skills: prioritization of requirements, decision modeling to structure choices, and solution evaluation to test whether value was actually delivered.
CAPM Connection
These skills sit mainly in the Business Analysis Frameworks domain but also support Project Management Fundamentals. They build on your earlier work with requirements and process models.
What You Will Practice
You will practice MoSCoW prioritization, decision tables, cause-and-effect diagrams, defining metrics, segmented evaluations, and clear stakeholder communications.
MoSCoW and Other Prioritization Techniques
MoSCoW Categories
MoSCoW splits requirements into Must-have, Should-have, Could-have, and Won't-have (this time). It forces explicit trade-offs instead of vague "high/low" labels.
Must vs Should
Must-have means the solution fails without it. Should-have is very important, but a workaround exists. Exam questions often hide Shoulds disguised as Musts.
Could and Won't
Could-have features are nice enhancements. Won't-have items are explicitly out of this release but documented, reducing future conflict and scope creep.
Other Techniques
You may also see simple ranking, release-based grouping, and value vs effort grids. These complement MoSCoW when refining the product backlog.
Worked Example: Prioritizing a Registration System with MoSCoW
Scenario Setup
You are improving a university course registration system. Six features are proposed: payment, seat view, dark mode, waitlist, calendar export, and two-factor authentication.
Align with Objectives
The main objective is to cut help-desk calls by 40%. Constraints include payment security standards and university security policies. These guide what is truly critical.
Classifying Must-haves
Online payment, real-time seat view, and two-factor authentication are Must-haves: they support revenue, reduce calls, or satisfy security policy.
Shoulds and Coulds
Automatic waitlist is a Should-have with a manual workaround. Calendar export and dark mode are Could-haves: they improve comfort but not objectives or compliance.
Decision Modeling: Gateways, Decision Tables, and Root Cause Tools
Why Model Decisions?
Decision modeling makes messy choices visible. It shows branching logic, complex rules, and underlying causes so that teams can analyze and test them.
Decision Gateways
Gateways in process models show where flow splits based on conditions. Each path should represent a clear, testable outcome, like payment approved vs declined.
Decision Tables
Decision tables list conditions and outcomes in a grid. They are ideal when many rule combinations exist and you want to avoid gaps or contradictions.
Root Cause Tools
Cause-and-effect diagrams and 5 Whys are used for root cause analysis. They help move from visible symptoms to deeper process, people, or technology causes.
Example: Building a Decision Table and Fishbone Diagram
Conditions and Actions
For registration rules, define conditions like GPA, course level, and prerequisites. Define actions like self-register, advisor approval, or block registration.
Decision Table Rules
List each rule as a combination of Y/N conditions leading to an action. Check that all realistic combinations of GPA, course level, and prerequisites are covered.
Finding Gaps
Review the table to ensure no missing or conflicting rules. This helps both developers and testers implement and validate the logic correctly.
Fishbone for Errors
For many registration errors, your fishbone might include People, Process, Technology, and Policy branches, each listing likely contributing causes.
Defining Pre- and Post-Implementation Metrics
Why Metrics?
To know if a solution worked, you need measurable evidence. That means defining metrics, capturing a baseline, and comparing results after implementation.
Align with Goals
Metrics must align with objectives. If your goal is fewer help-desk calls, track call volume and duration, not just page views or logins.
Define and Baseline
Give each metric a name, unit, scope, and data source. Then capture pre-implementation values so you can later compare against them.
Compare and Interpret
After go-live, measure again and compare. Improvements suggest value, but also watch for side effects like new bottlenecks or user drop-offs.
Segmented Solution Evaluation and Workarounds
Why Segment?
Different stakeholder groups experience the same solution differently. Segmenting evaluation reveals whether all key groups are actually benefiting.
Examples of Segments
You might compare new vs returning students, domestic vs international, or front-line staff vs managers, each with their own metrics and concerns.
Workarounds and Bypasses
When users avoid the official process, they are signaling pain. Workarounds often reveal gaps in process, policy, training, or technology.
Diagnose, Don't Blame
Instead of blaming users, analyze why they bypassed workflows and recommend changes to steps, rules, training, or system design.
Communicating Evaluation Results to Stakeholders
Audience First
Executives, front-line staff, and technical teams need different views. Tailor depth, language, and visuals to each group’s interests and decision authority.
Useful Formats
Use process diagrams to show workflows, prototypes to show screens, and executive summaries to present objectives, metrics, findings, and recommendations.
Make It Clear
Use plain language, highlight before vs after metrics, and state what decision or action is needed. Avoid drowning stakeholders in raw data.
Feedback Loops
Check understanding by asking stakeholders to paraphrase or react. Their questions often reveal misunderstandings you can fix early.
Thought Exercise: From Vague Requirement to Testable Metric
Try this short exercise to practice turning vague statements into measurable evaluation criteria.
Scenario
A stakeholder says: "The new registration system should be much faster and less confusing for students."
Your tasks
- Rewrite this as two separate, testable requirements (one for speed, one for usability/clarity).
- For each requirement, propose one metric you would measure before and after implementation.
- Decide which stakeholder segments you would collect data from.
Pause and write your answers before revealing the sample solution.
---
Sample approach (compare to your answer)
- Testable requirements:
- Speed: "The system shall allow a typical undergraduate student to complete course registration in under 8 minutes during peak hours."
- Usability: "At least 80% of surveyed students shall rate the registration process as 'easy' or 'very easy' one month after launch."
- Metrics:
- Speed metric: Average completion time (minutes) from login to confirmation during the first week of registration.
- Usability metric: Percentage of students selecting 'easy' or 'very easy' on a post-registration survey.
- Segments:
- New vs. returning students (new students may find it more confusing).
- Domestic vs. international students (language and policy differences).
On the exam, similar items test whether you can convert vague desires into measurable criteria and link them to specific metrics and stakeholder groups.
Quiz 1: Prioritization and Decision Modeling
Answer this CAPM-style question to check your understanding of MoSCoW and decision tools.
A team is overwhelmed by 60 proposed features for a new internal portal. Budget and time allow only about half to be delivered in the first release. Some features are legally required, while others are convenience improvements. The project manager asks you to recommend an approach that both clarifies trade-offs and ensures compliance items are not missed. What is the BEST next step?
- Ask each stakeholder to rank their top 10 features and implement the most frequently mentioned ones.
- Apply MoSCoW prioritization with stakeholders, explicitly classifying requirements as Must-have, Should-have, Could-have, or Won't-have, and verifying that all legal and compliance items are in the Must-have group.
- Create a fishbone diagram of all requested features to identify root causes and then select only those that address the main causes.
- Use a decision table to list all 60 features and mark which stakeholder requested each, then prioritize features requested by the most stakeholders.
Show Answer
Answer: B) Apply MoSCoW prioritization with stakeholders, explicitly classifying requirements as Must-have, Should-have, Could-have, or Won't-have, and verifying that all legal and compliance items are in the Must-have group.
MoSCoW is designed to categorize requirements into Must-have, Should-have, Could-have, and Won't-have, making trade-offs explicit. It is especially useful when you must limit scope but cannot miss compliance-related Must-haves. Ranking by popularity or requester count can overlook legal requirements, and fishbone diagrams are for root cause analysis, not prioritizing a feature list.
Quiz 2: Solution Evaluation and Workarounds
Check your understanding of metrics and segmented evaluation.
After a new registration system goes live, overall help-desk calls drop by 45%, but calls from international students increase by 20%. Staff also begin manually enrolling many international students using a back-end tool instead of the official front-end workflow. As a CAPM-level practitioner, what should you do FIRST?
- Recommend turning off the back-end tool so staff are forced to use the new workflow as designed.
- Conclude that the project is a success because total calls decreased and prepare the final report.
- Conduct segmented solution evaluation focused on international students and investigate why staff are using the workaround, examining process, policy, training, and technology factors.
- Ask the development team to immediately add more servers to improve system performance for all users.
Show Answer
Answer: C) Conduct segmented solution evaluation focused on international students and investigate why staff are using the workaround, examining process, policy, training, and technology factors.
The key issue is that one stakeholder segment (international students) is experiencing problems that lead to workarounds. The appropriate first step is segmented solution evaluation and root cause investigation across process, policy, training, and technology. Disabling the workaround or declaring success ignores these issues, and adding servers may not address usability or policy problems.
Key Term Review: Prioritization, Decisions, and Evaluation
Flip these cards to reinforce core concepts that commonly appear on CAPM questions.
- MoSCoW prioritization
- A technique that categorizes requirements into Must-have, Should-have, Could-have, and Won't-have (this time), helping stakeholders make explicit trade-offs under constraints.
- Decision gateway
- A point in a process model where the flow branches based on conditions (e.g., yes/no, approved/rejected), representing different possible paths and outcomes.
- Decision table
- A structured grid that lists conditions and corresponding actions or outcomes, used to analyze and implement complex business rules and ensure all combinations are covered.
- Cause-and-effect (fishbone) diagram
- A root cause analysis tool that starts with a problem and visually organizes possible causes into categories such as People, Process, Technology, Policy, and Environment.
- Pre-implementation metric (baseline)
- A measurement taken before a solution is implemented, used as a reference point to compare with post-implementation results and determine whether value was delivered.
- Segmented solution evaluation
- Assessing solution performance separately for different stakeholder groups or user segments to see whether each group’s needs are met and to uncover hidden issues.
- Workaround
- An unofficial or alternative method that users adopt to bypass part of the designed process or system, often signaling problems with process, policy, training, or technology.
- Executive summary (in evaluation)
- A concise, high-level communication that presents objectives, key metrics, major findings, and recommended actions in plain language for decision makers.
- Root cause analysis (RCA)
- A set of techniques, such as 5 Whys and fishbone diagrams, used to identify the underlying causes of a problem rather than just treating its symptoms.
- Product backlog
- An ordered list of everything that is known to be needed in the product, managed by the product owner.
Key Terms
- Workaround
- An informal or temporary method used to complete work when the official process or system is difficult, slow, or unusable.
- Decision table
- A tabular representation of conditions and resulting actions used to define and analyze complex business rules.
- Baseline metric
- A measurement of performance taken before a change, used as a reference point to evaluate the impact of a solution.
- Product backlog
- An ordered list of everything that is known to be needed in the product, managed by the product owner.
- Decision gateway
- A branching point in a process model where different paths are taken based on defined conditions.
- Executive summary
- A brief, high-level overview of an analysis or report tailored for decision makers, focusing on key findings and recommendations.
- Root cause analysis
- An approach that seeks to identify the fundamental causes of a problem so that effective solutions can be implemented.
- MoSCoW prioritization
- A technique that categorizes requirements into Must-have, Should-have, Could-have, and Won't-have (this time) to support explicit trade-offs.
- Cause-and-effect diagram
- Also called a fishbone or Ishikawa diagram, a visual tool for organizing possible causes of a problem into logical categories.
- Segmented solution evaluation
- Evaluation of solution performance by distinct stakeholder or user groups to identify differences in outcomes or issues.