Skip to content
NTPU AI Learn

AD 103 · Module 2

Prioritize

Compare multiple Use Cases on the same dimensions, discuss portfolio trade-offs, and complete the Prioritization Workshop.

Start Section 1
  • Duration90 min
  • LevelCore
  • PrerequisiteAD 101 / AD 102 recommended first
0 / 3 completed
Sync my progressJoin a session to keep progress across devices and share it with your instructor

Info

After you join, your completed lesson numbers are sent to your instructor together with your learner code, so they can see your progress. Use the codes your instructor gave you, and do not enter your name, company secrets or other personal data. Progress is kept with the rest of that session's data.

Learning objectives

  • Compare cases on the same dimensions, with evidence quality and confidence made explicit.
  • Record disagreement, assumptions, unknowns, and resource constraints.
  • Form a next step, an owner, and a review date for every Use Case.

Compare Use Cases

30 min

Compare Use Cases

Learning objective: Compare cases on the same dimensions, with evidence quality and confidence made explicit.

When comparing multiple Use Cases, they must be compared on the same set of dimensions (Value, Feasibility, Readiness, Risk) one by one, rather than each case being judged by its own different standard. Each dimension's evidence quality and confidence level must also be labeled: is this judgment backed by data, or is it a pure guess? Different confidence levels mean different reliability in the comparison.

Two layers of information when comparing
FieldMeaning
Dimension judgmentThe assessment on each of Value/Feasibility/Readiness/Risk
Evidence confidenceIs this judgment observed/data-backed or estimated/a guess?
Workplace example

Comparison: Use Case A: Value high (data-backed), Feasibility medium (estimated, unverified), Risk low. Use Case B: Value medium (estimated), Feasibility high (data-backed), Risk medium. Since A's Value judgment carries more confidence than B's, A may be worth prioritizing for validation even if the other dimensions are close.

  • High confidence (data-backed): a judgment supported by system logs, formal statistics, or repeated observation.
  • Medium confidence (partially verified): supported by some data or a small sample, but not yet checked broadly.
  • Low confidence (estimated/guess): mainly a single interviewee's impression or guess, with no concrete data behind it.
  • When two cases score close on a dimension, trust the judgment with higher confidence first, rather than simply averaging them.
Workplace example (contrast case: comparing three cases)

Expanding to three candidates: Use Case A (Value high/high confidence, Feasibility medium/low confidence, Risk low/high confidence), Use Case B (Value medium/high confidence, Feasibility high/high confidence, Risk medium/medium confidence), Use Case C (Value high/low confidence, Feasibility high/low confidence, Risk low/low confidence). C looks good on the surface across all three dimensions, but every number is a low-confidence estimate, so it may need a short follow-up interview to gather evidence before it goes on the priority list, rather than being ranked on guesses alone.

Info

Human, AI, Human: a person makes the final prioritization and governance decisions; AI may help organize comparison data, but never makes the final call for the organization.

Warning

Data safety reminder: every exercise in this course uses course-provided synthetic scenarios only, never real institutional or personal data.
Check yourself

When comparing two Use Cases, which approach is most correct?

When comparing two Use Cases, which approach is most correct?

Key takeaway: Comparing Use Cases means using the same dimensions, with the evidence confidence behind each judgment honestly labeled.

Portfolio Discussion

30 min

Portfolio Discussion

Learning objective: Record disagreement, assumptions, unknowns, and resource constraints.

During a portfolio review discussion, participants often disagree about the same Use Case. A good discussion record does not force away disagreement, it honestly records: where there is disagreement, what unverified assumptions surfaced during discussion, which unknowns still have no answer, and how current resource constraints affect the decision.

Four things to honestly record
FieldMeaning
DisagreementWhere do views differ?
AssumptionWhat unverified assumptions surfaced?
UnknownWhat questions still have no answer?
Resource constraintWhat is the current resource limit?
Workplace example

Discussion notes: on Use Case A's Readiness, the manager thinks "we're ready" while the coordinator thinks "the manager is underestimating resistance to the process change" (disagreement). Both assume "employees will be willing to switch to the new system" (assumption, unverified). It's unclear whether IT can support the integration this quarter (unknown). Only one squad is available this quarter (resource constraint).

  1. Watch for signs of disagreement
    When two participants state different judgments about the same dimension, write down both statements verbatim on the spot instead of rushing to reconcile them.
  2. Probe the assumption behind it
    Asking "what are you assuming when you say that?" often surfaces an assumption neither side had said out loud.
  3. Flag unknowns explicitly
    When someone says "we're not sure about this yet," record it as an unknown rather than forcing an answer out of them.
  4. Record the resource constraint
    Ask "how much time or headcount can we actually commit this quarter?" and write the limit down: it shapes the prioritization that follows.
  • Phrase that signals disagreement: "I see this differently from [name]: I think..."
  • Phrase that signals an assumption: "We're both assuming... but we haven't verified it."
  • Phrase that signals an unknown: "We don't know this yet; it needs to be confirmed."
  • Phrase that signals a resource constraint: "This quarter we can only commit... of time or headcount."

Info

Human, AI, Human: a person makes the final prioritization and governance decisions; AI may help organize comparison data, but never makes the final call for the organization.
Check yourself

In a portfolio review, the manager and the coordinator disagree on a case's Readiness. Which way of recording it is most correct?

In a portfolio review, the manager and the coordinator disagree on a case's Readiness. Which way of recording it is most correct?

Key takeaway: Portfolio discussion notes should honestly show disagreement, assumptions, unknowns, and resource constraints, not manufacture false consensus.

Prioritization Workshop

30 min

Prioritization Workshop

Learning objective: Form a next step, an owner, and a review date for every Use Case.

This is the course's capstone activity: integrate everything from the previous six lessons (portfolio thinking, value, feasibility, readiness, risk, comparison, and discussion) into the formal AI Use Case Portfolio. Every Use Case must end with an explicit next step (one of clarify, prototype, pilot-review, governance-review, defer, or stop), an owner responsible for moving it forward, and a review date for when it will next be checked.

Three closing fields per Use Case
FieldMeaning
Next stepclarify / prototype / pilot-review / governance-review / defer / stop
OwnerWho is responsible for the next step?
Review dateWhen is the next check-in?
Workplace example

Workshop output: Use Case A: next step = prototype; owner = the systems team lead; review date = in six weeks. Use Case B: next step = governance-review (involves financial risk); owner = the CFO; review date = in two weeks (governance review first).

  • Clarify: the problem statement or owner still isn't clear enough; the next step is a follow-up interview, not jumping straight into work.
  • Prototype: direction is clear and risk is manageable, so a small, verifiable prototype is worth the time.
  • Pilot-review: the prototype has proven itself and is ready for a limited-scope formal trial, with a review scheduled afterward.
  • Governance-review: the case touches personal data, finance, regulation, or security risk and must clear governance review before it can continue.
  • Defer: the timing or resources aren't right yet, but the case is kept on file with a date set to revisit it.
  • Stop: after evaluation, the case is confirmed not worth pursuing and is closed explicitly, instead of quietly draining the team's attention.
Workplace example (contrast case: applying the six-option decision)

Use Case C (library Q&A assistant): Value medium, Feasibility high, Readiness low (the library hasn't named an owner yet), Risk low. Applying the six options: because Readiness is insufficient, the right choice is clarify, not jumping straight to prototype; the next step is asking the library to name an owner and confirm operating capacity. Owner = the Teaching and Learning Center; review date = in three weeks, to confirm whether the library has named an owner.

Info

Human, AI, Human: a person makes the final prioritization and governance decisions; AI may help organize comparison data, but never makes the final call for the organization.
Check yourself

At the end of the workshop, a Use Case only says "this looks good, let's continue." What feedback is most appropriate?

At the end of the workshop, a Use Case only says "this looks good, let's continue." What feedback is most appropriate?

Key takeaway: The workshop's completion bar: every Use Case has an explicit next step, owner, and review date, not a vague "let's continue".

Save as PDF

What next?