Evaluate

25 min

Portfolio Thinking

Learning objective: Under limited resources, think in terms of a portfolio rather than a single case, weighing dependency, capacity, and learning value.

With several candidate Use Cases in hand, you cannot evaluate them one at a time and just pick whichever scores "highest". Portfolio thinking considers them together: are there dependencies between cases (e.g. one must finish before another can start), what is the team's current execution capacity, and what learning value comes from doing a smaller case first (e.g. validating an assumption that reduces risk for a later case).

• Dependency, extended case: Use Case D (cross-system report integration) must wait for Use Case E (data-warehouse rollout) to finish, a clear sequencing relationship.
• Capacity, extended case: the team can only deeply support one pilot at a time; forcing three cases live simultaneously means each gets stretched thin and slips.
• Learning value, extended case: running one small classification case first to confirm "can AI classification's manual-correction rate stay under 10%" produces a lesson that applies to every larger case after it.
• When the three dimensions conflict (e.g. the case with the highest learning value happens to have the lowest capacity), honestly record the trade-off instead of forcing a single ranking.

Key takeaway: Facing multiple candidate Use Cases, look at them together as a portfolio, not by scoring each in isolation.

25 min

Value & Outcome

Learning objective: Separate activity from outcome; value can include time, quality, capacity, cost, service, and strategic dimensions.

When assessing Value, first confirm whether what is written is an outcome or an activity. Value is not one dimension, it may include time (shorter processing), quality (fewer errors), capacity (more cases handled with the same staff), cost (lower spend), service (higher satisfaction), and strategy (supporting long-term organizational goals). The same Use Case may bring several kinds of value at once, and each should be written out separately rather than vaguely claiming "it has value".

• Time: how long does handling one case drop from, and to? Use a concrete number, not just "faster".
• Quality: do error rate, rework rate, or complaint volume drop?
• Capacity: how much more can the same staff handle? Or does overtime that used to be needed go away?
• Cost: is outsourcing spend, material waste, or some other direct cost reduced?
• Service: does satisfaction or perceived wait time improve for the user or applicant?
• Strategy: does it support a long-term goal the organization has already announced (e.g. digital transformation, sustainability, service quality)?

Key takeaway: Value should be broken into concrete dimensions and described separately, not waved away with a vague feeling.

20 min

Feasibility & Readiness

Learning objective: Record technical feasibility and organizational readiness separately.

Feasibility asks about technical and integration complexity: can the data be obtained, can systems be connected, is AI capability sufficient. Readiness asks about the organizational side: is there a clear owner, can the workflow accommodate change, does the team have the capacity to execute, does it fit existing policy. The two are easily conflated, but being technically feasible does not mean the organization is ready, and vice versa, they must be recorded separately.

1. 1Ask Feasibility first
   Where does the needed data live? Is the format clean? Does the system to be integrated have an open interface?
2. 2Then ask Readiness
   Who is the owner? Can that unit's way of working accommodate the change? Does the team have the time and ability to execute?
3. 3Mark each dimension separately
   Rate each as high/medium/low on its own; do not let one dimension color the other.
4. 4Find where the real investment is needed
   Whichever dimension scores low tells you where to spend time communicating or preparing next.

Key takeaway: Being technically feasible does not mean the organization is ready, always record feasibility and readiness separately.

20 min

Risk & Governance

Learning objective: Keep risk visible rather than hiding it as a deduction in a total score; escalate to governance review when needed.

The point of risk assessment is not to deduct points, but to let decision-makers clearly see what risk exists and what the consequence would be. Folding risk into a negative number buried inside a total score can let a genuinely high-risk case get averaged away and become hard to spot. When risk is clearly high (e.g. involving personal data, financial decisions, regulatory compliance), it should go straight to a governance review rather than letting the Use Case pass on its own.

• Personal-data risk: does it involve sensitive information about a student, employee, or other individual?
• Financial risk: does it involve approving amounts, allocating budget, or a possible financial loss?
• Regulatory-compliance risk: does the decision need to satisfy a specific law or policy?
• Safety risk: could a wrong output affect someone's physical safety or a major right?
• If any one of these is clearly present, route it to governance review first, rather than waiting until every dimension's score is tallied.

Key takeaway: Risk must be clearly visible and recorded independently; high-risk cases should escalate straight to governance review, not get averaged away in a total score.