Published on
Prioritize AI Projects in 90 Minutes: Workshop Ready Scorecard for PMs
The fastest way to prioritize AI projects is a score based portfolio method: rank each candidate by expected business impact, data readiness, and deployment effort, then adjust for AI specific risk. Push the top scoring cluster into a short workshop, thirty to ninety minutes, and convert whatever survives into a pilot. A copyable scorecard and the workshop steps that turn scores into decisions follow.
TL;DR:
Projects that lack a data source, regulatory approval, or an accountable owner should be disqualified during triage to avoid wasting effort on unviable ideas.
Data readiness is the most decisive factor in project prioritization, with a score of five nearly guaranteeing inclusion in the pilot pipeline if the project scores well elsewhere.
Effort estimates focusing solely on model development are almost always inaccurate, as most effort and risk lie in data engineering, deployment, and ongoing maintenance.
Incorporating risk and compliance checks into the scoring process ensures high-stakes projects are appropriately scrutinized before approval rather than after pilot initiation.
Sequencing projects based on explicit data and infrastructure dependencies prevents downstream delays and maintains smooth rollout progress across the portfolio.
BRDGITTurn AI Priorities Into ActionBRDGIT helps teams assess readiness, identify opportunities, build roadmaps, and move selected AI projects toward implementation.Explore BRDGIT
Table of Contents
Building a repeatable AI project prioritization framework
Heuristics that shape realistic AI scoring and budgets
A scorecard you can build in a spreadsheet this week
Turning the scorecard into a working prioritization habit
How BRDGIT turns a ranked backlog into a delivered pilot
Sequencing AI projects when one depends on another
Weighing hard numbers against team judgment in scoring sessions
Building compliance and ethics checks into the scoring process
Practitioner perspective: what changes in a PM’s daily work
How BRDGIT supports each stage of prioritization
Where to check the frameworks behind this article
Sources
FAQ
Building a repeatable AI project prioritization framework
Most AI backlogs fail before scoring even starts, because intake is sloppy and everyone assumes someone else owns the data. A working framework fixes that with four stages: intake, triage, scoring, and decision.
Intake: every candidate submits a short form with a problem statement, a named sponsor, a baseline metric to move, a named data owner, and a rough effort estimate in weeks.
Triage: a fast pass separates viable ideas from dead ones before anyone spends time scoring them.
Scoring sprint: a time boxed session, calibrated across reviewers, produces a ranked list.
Decision: each project exits with a clear gate outcome.
Triage rules matter more than most teams expect. Kill or park anything with no identifiable data source, anything blocked by a known regulatory constraint, or anything with no accountable owner. Fast pass anything with a clean baseline metric, an engaged sponsor, and data that already exists in a usable form.
Disqualify projects where “the data probably exists somewhere” is the honest answer.
Fast track projects where a sponsor can name the metric they expect to move within one quarter.
Flag anything touching regulated decisions (credit, hiring, health) for a compliance check before scoring.
Decision gates should produce one of four outcomes: pilot now, incubate with a data or staffing fix first, defer to a later planning cycle, or kill outright. A prompt-based discovery method can speed up the intake stage by surfacing automation candidates your team hasn’t formally logged yet.
Pro Tip: Cap the intake form at ten fields. Longer forms get abandoned or filled in with guesses, which corrupts the scoring session before it starts.
Heuristics that shape realistic AI scoring and budgets
Raw scoring numbers mean little without a mental model behind them. A few heuristics, borrowed from practitioners who have run AI portfolios before, keep the scoring honest.
The 10-20-70 rule holds that model work is a minority share of the effort, with technology and especially people and process work making up the larger part, according to a practical explainer on the framework. Overfund the model and underfund training or workflow redesign, and the pilot stalls at rollout, not at the algorithm.
The 30% rule frames model development as a minority share of the total workload, with most of the effort and risk sitting in data engineering and ongoing deployment and maintenance, per a guide for business leaders. Effort estimates that only account for model build time are almost always wrong.
MoSCoW and horizon models slot projects into short term wins versus transformational bets, which keeps a portfolio from becoming all moonshots or all trivial automations.
CPMAI style practitioner frameworks treat AI projects as data projects first, a distinction that changes what a project manager tracks week to week, according to PMI’s guidance for AI ready project managers.
The 10-20-70 rule advises that AI transformation success depends mostly on people and process work, about 70% of total effort, which means a scoring session that only rates technical feasibility is measuring the smaller half of the problem.
A scorecard you can build in a spreadsheet this week
A workable scorecard needs six dimensions, each scored on a simple numeric scale, so reviewers can compare wildly different project types on the same terms.
Expected impact: the size of the metric movement, tied to the baseline named at intake.
Effort: the total build and deployment time, not just the modeling phase.
Data readiness: whether usable, labeled, accessible data already exists.
Technical feasibility: whether the approach is proven elsewhere or genuinely novel.
Risk and trustworthiness: exposure if the system is wrong, biased, or unmonitored.
Strategic fit: alignment with a named business priority, not a vague aspiration.
Score each dimension one to five, with five always meaning “best case for moving forward.”
Weight impact and data readiness higher than the others, roughly double the weight of feasibility or strategic fit, since a project with poor data readiness will underperform regardless of how good the model is.
Multiply each score by its weight, sum the totals, then bucket results into pilot, incubate, monitor, or kill.
Consider a hypothetical scheduling optimization project: impact scores four, effort scores three (meaning moderate effort), data readiness scores five, feasibility scores four, risk scores four, strategic fit scores five. With impact and data readiness weighted at two and the rest at one, the weighted total lands well inside the pilot bucket, mainly because the data already exists in usable form. That single dimension, more than any other, tends to decide whether a project belongs in this quarter’s pilot slate. The criteria used to rank AI projects by value and feasibility work the same way in production portfolios, not just in worked examples.
Turning the scorecard into a working prioritization habit
A scorecard only matters once a team actually runs it on a schedule. The workshop format below fits inside a single meeting slot and produces a ranked backlog by the time people leave the room.
Intake review (10 minutes): confirm every candidate has a sponsor, a baseline metric, and a data owner.
Individual scoring (15 to 30 minutes): each reviewer scores independently, without discussion, to avoid anchoring on the loudest voice in the room.
Calibration (15 to 30 minutes): compare scores, resolve gaps larger than two points, and flag disagreements about data readiness specifically, since that’s where estimates diverge most.
Decision (10 to 15 minutes): assign each project to pilot, incubate, defer, or kill, and name who owns the next step.
Keep four artifacts alive between sessions: the intake form, the live scorecard, a roadmap swimlane showing sequencing, and a risk log for anything flagged during calibration. Assign one person to update scores monthly, one to run each approved pilot, and one, usually a steering sponsor, to sign off before anything moves from pilot to scaled production.
Pro Tip: Run calibration before decision every time. Skipping it is the single fastest way to end up with a backlog full of ties that nobody wants to break.
The most common pitfalls are predictable: no named data owner, decision paralysis when scores cluster too closely, and effort estimates that ignore ongoing operational cost after launch.
How BRDGIT turns a ranked backlog into a delivered pilot
A scorecard tells you what to build first. Getting it built is a separate problem, and it’s the one most internal teams underestimate once the workshop ends.
The delivery pattern follows the same logic this framework describes: an assessment establishes whether the data and process support the top ranked candidates, a blueprint turns the survivors into a sequenced roadmap, and engagements or fractional engineering services carry the pilot from approved concept to running system without the client hiring a full AI team.
An AI readiness assessment checks data readiness and organizational fit before a single pilot is greenlit.
A blueprint converts a scored backlog into a sequenced, resourced roadmap.
Workflow and custom agent build engagements deliver the highest scoring automation and agent projects.
Fractional engineering services cover ongoing execution for teams that need engineering depth without a full time hire.
Teams that pair a disciplined scoring process with hands-on delivery support tend to see shorter pilot cycles, clearer ROI attribution, and steadier staff adoption, since the roadmap and the build stay connected instead of drifting apart after the workshop ends.
Sequencing AI projects when one depends on another
Almost no AI portfolio is a flat list. One project’s output feeds another’s input, and treating them as independent scoring lines produces a roadmap that looks fine on paper and falls apart in execution.
Start by mapping data dependencies explicitly: if a customer segmentation model needs a cleaned customer record as a prerequisite, the record cleanup project outranks the segmentation model regardless of its own standalone score. Infrastructure dependencies work the same way. A dashboard project that visualizes model output cannot start meaningfully until the model itself produces stable, trustworthy predictions, so sequencing it earlier just moves idle work forward in the calendar.
A simple rule helps: any project that another pilot depends on for data, infrastructure, or a validated baseline gets promoted at least one bucket above its raw score, because its true value includes everything downstream of it. Conversely, a high scoring project that depends on an unfinished prerequisite should be marked incubate rather than pilot, even if its own scorecard total looks strong.
The roadmap swimlane from the workshop section should show these dependencies visually, with arrows connecting prerequisite work to what it unlocks. Reviewing that swimlane monthly, alongside the scorecard, catches the case where a dependency quietly slips and strands two or three other projects behind it. Teams that skip this step tend to discover the problem only when a pilot misses its launch date because a prerequisite dataset was never actually finished.
Weighing hard numbers against team judgment in scoring sessions
Scoring works best when it blends what the numbers say with what the room already knows. Pure quantitative scoring, run mechanically off a spreadsheet formula, tends to undervalue projects where the real risk is political or organizational rather than technical. Pure qualitative judgment, run entirely on gut feel, tends to overvalue whichever project the most persuasive person in the room happens to champion.
Quantitative inputs belong wherever they exist: a measured baseline metric, an actual count of records in a proposed training dataset, or a documented cost estimate for infrastructure. These numbers anchor the impact and effort dimensions of the scorecard and stop the session from drifting into pure opinion.
Qualitative input still carries real weight, particularly on strategic fit and risk. A sponsor’s read on whether frontline staff will actually adopt a new tool, or a compliance officer’s instinct that a use case sits close to a regulatory line, rarely shows up in a clean number but should still move a score. The calibration step described in the workshop section exists precisely to surface this kind of judgment before it gets buried under a spreadsheet total.
The practical rule: let hard data set the baseline score, then let structured discussion during calibration adjust it up or down by no more than one point per dimension. That cap keeps persuasive arguments from overriding evidence entirely, while still letting the room’s collective judgment catch what the numbers alone would miss.
Building compliance and ethics checks into the scoring process
Skipping risk and compliance review until after a pilot is built is how AI projects turn into expensive rework. The fix is to fold ethical and regulatory review into the scorecard itself, not into a separate approval step that happens after the fact.
The NIST AI Risk Management Framework offers the clearest starting point available to project managers who aren’t compliance specialists. It recommends prioritizing risk based on assessed impact and context, meaning a system that influences hiring, credit, or health outcomes needs more urgent, thorough risk management than a low stakes internal reporting tool. That guidance maps directly onto the risk and trustworthiness dimension of the scorecard: score higher stakes projects more conservatively, and require stronger evidence of monitoring and human oversight before they move from pilot to scale.
Practically, that means adding two questions to every intake form: does this project make or influence a decision about a person, and is there a regulatory framework that already governs this use case in your sector. Either answer being yes should trigger a compliance review before scoring even begins, not after a pilot is already running. Projects that clear this check still deserve ongoing monitoring once deployed, since a model’s risk profile can shift as the data feeding it changes.
Treating compliance as a scoring input, not an afterthought, keeps the highest risk projects from sailing through a workshop on the strength of their impact score alone.
Practitioner perspective: what changes in a PM’s daily work
Once AI projects sit in the portfolio, the job shifts. Routine status tracking and data wrangling get automated or delegated; stakeholder alignment and adoption design become the harder, higher value work. According to Gartner’s analysis of AI’s effect on the role, a project manager who uses AI well will outperform one who doesn’t, which makes AI fluency a core skill, not an optional add-on, alongside stakeholder management and change design. A reasonable one week action: block two hours to run the intake and triage steps above on your current backlog before adding anything new.
— Team BRDGIT
How BRDGIT supports each stage of prioritization
Running the framework above with a small internal team is doable. Running it while also keeping the rest of your project load moving is where most teams stall out, and it’s the gap BRDGIT is built to close.
AI Readiness Assessment and AI Blueprint cover the intake and scoring stages, checking data readiness before anything hits the roadmap.
Workflow Crew and Custom Agent Build deliver the pilots that clear the scorecard.
Fractional Engineer Services and Managed AI Support keep delivery moving without a full time hire.
BRDGIT’s approach stays modular and fast starting, built for small and mid-sized teams rather than a bloated platform rollout. If your backlog is scored and you need hands to build the top pilots, start with the AI Blueprint and readiness services or look at fractional engineering support for ongoing delivery.
Where to check the frameworks behind this article
NIST AI Risk Management Framework for risk prioritization guidance.
Gartner’s analysis of AI and project management for the PM augmentation case.
10-20-70 rule explainer and the 30% rule guide for effort heuristics.
A scheduling optimization pilot guide for a real pilot design reference.
Sources
FAQ
What is the 30% rule for AI?
The 30% rule is a heuristic stating that model development represents a minority of total project effort, with most of the work and risk concentrated in data engineering and deployment or maintenance. It’s used to correct effort estimates that only account for building the model itself.
What is the 10-20-70 rule for AI?
The 10-20-70 rule breaks AI transformation effort into roughly 10% algorithms, 20% technology, and 70% people and process work. It’s a reminder that adoption and workflow redesign usually determine success more than the model itself.
What are the stages of an AI project cycle?
Definitions vary across frameworks, but a common version follows intake, triage, scoring, decision, and delivery, then monitoring once a pilot moves to production. This article’s framework maps directly onto that cycle, from the intake form through the workshop decision gate.
Can AI replace a PMP-certified project manager?
No credible source suggests AI replaces certified project managers outright. Analysis from Gartner instead frames AI as an augmentation tool, arguing that a project manager who uses AI effectively will outperform one who doesn’t, which shifts the role toward higher-leverage strategic work rather than eliminating it.
How do I start prioritizing AI projects this week?
Build the intake form described above, run triage on your current idea list to remove anything with no data owner or clear sponsor, then score what remains using the six-dimension scorecard. A thirty to ninety minute workshop is usually enough to convert a scored list into a first pilot decision.
