Every company I work with arrives with a list. Twelve ideas, maybe twenty, generated over eighteen months of demos, articles, and conversations.
The list is not the problem. The problem is that nothing on it is ranked, so the project that gets built is whichever one the most persuasive person in the room advocated for most recently.
Short answer: score every candidate on four factors. Value, feasibility, risk, and adoption readiness. Multiply the scores rather than adding them, because a single weak factor should sink a candidate rather than being averaged away. Then override the ranking once, in favour of a contained first project that proves the method.
The four factors
Value
What does changing this workflow produce in a year.
Score it on the honest number, not the theoretical one. Hours removed are not value until you can name what the business does with them. Faster response time is value when you can point to enquiries currently lost to delay.
- 1 We think it would help
- 3 We can estimate the benefit within a wide range
- 5 We have a measured baseline and a defensible target
Feasibility
Can this actually be built against your systems and data as they exist today.
- 1 Data is scattered, systems are closed, nobody has checked
- 3 Data exists with known quality problems, systems are modern but untested
- 5 Clean data, confirmed system access, process documented
Most optimism dies here, which is why it belongs early in the scoring rather than late.
Risk
What is the worst outcome if the system gets it wrong, and how quickly would you know.
Score this inverted, so 5 means low risk.
- 1 Money moves, contracts commit, regulated data is involved, errors would be invisible
- 3 Customer-facing but reversible, errors would surface within days
- 5 Internal, reviewed by a human before use, errors are obvious immediately
Adoption readiness
Will the people whose work changes support this.
- 1 They have not been consulted and would resist
- 3 Neutral, would use it if it worked
- 5 They raised the problem themselves and want it solved
This is the factor most scorecards omit and the one that most reliably kills a technically sound project.
Multiply, do not add
Here is the trap.
Two candidates. The first scores 5 on value, 4 on feasibility, 4 on risk, and 1 on adoption readiness. Total of 14. The second scores 4, 4, 4, and 4. Total of 16.
Add them and the gap is narrow enough that the first one’s exciting value score wins the argument. Multiply and the first scores 80 against the second’s 256. The gap becomes what it actually is.
That is the correct behaviour. A workflow the affected team will refuse to use is not a slightly weaker project. It is a different category of thing.
The same logic applies to feasibility. A candidate scoring 1 on feasibility is not 20% worse than one scoring 5. It is a project that will consume a quarter discovering it cannot be built.
Worked example
A Calgary professional services firm, described as a scenario rather than a client.
| Candidate | Value | Feasibility | Risk | Adoption | Score |
|---|---|---|---|---|---|
| Proposal first drafts from past work | 5 | 4 | 4 | 4 | 320 |
| Internal knowledge search over past reports | 3 | 5 | 5 | 5 | 375 |
| Automated client billing adjustments | 5 | 3 | 1 | 2 | 30 |
| Weekly management brief assembly | 3 | 4 | 5 | 4 | 240 |
| Client-facing intake chatbot | 4 | 3 | 2 | 3 | 72 |
Two things worth noticing.
The knowledge search outranks proposal drafting despite lower value, because it is easier, safer, and the team actively wants it. That is the correct ranking for a first project.
The billing automation, which had the highest raw value in the room when this list was generated, ranks last. High value, high risk, low feasibility, and a team that has not been consulted. Additive scoring would have placed it third.
The one override
After ranking, apply a single override for your first project.
Choose the highest-ranked candidate that is also contained, low risk, and self-evidently useful to the people doing the work. Even if a slightly higher-scoring option exists.
The first project has a job beyond its own return. It teaches the organization the method, produces a picture people can recognize, and generates the internal confidence to fund the second. A first project that is technically superior but organizationally disruptive costs you the sequence.
After the first, rank purely on score.
Where this framework does not apply
Regulatory or compliance-driven work. If a system is required rather than chosen, it does not compete on this scorecard. Build it.
Foundational data work. Cleaning a customer database scores badly on value because the benefit is indirect. If three of your top candidates all depend on that data, the cleanup is a dependency, not a competitor.
Very small businesses with one obvious candidate. If you have two ideas and one of them is clearly the pain, scoring is theatre. Build it.
Anything where the process is undocumented. Score it if you like, but the real first project is writing the process down.
Running the scoring session
Get the department leads in a room for ninety minutes. Score together rather than collecting scores separately, because the disagreements are where the useful information lives.
When two people score the same candidate 2 and 5 on feasibility, stop and find out why. Usually one of them knows something about the data that the other does not.
Record the reasoning next to each score. Six months later, when someone asks why the billing project was deprioritized, the reasoning is the answer, not the number.
FAQ
How many candidates should we score?
Eight to fifteen. Fewer suggests you have not asked enough departments. More means you are scoring tasks rather than processes.
Should we weight the factors differently?
Resist it. Weighting invites the room to adjust the weights until the preferred answer wins. If a factor genuinely matters more in your business, say so in the discussion rather than encoding it.
What if everything scores low?
Then your first project is readiness work rather than an automation. That is a useful finding and it saves you a failed build.
How often should we rescore?
After each completed project, or when something material changes such as a new system, a data cleanup, or a key departure.
Can we score a candidate we do not fully understand?
Score feasibility as 1 and move on. Uncertainty is a feasibility problem and the framework handles it correctly.
Where to go next: Run the scoring session with your department leads. Ninety minutes, one whiteboard, reasoning recorded beside every score. It usually reorders the list more than people expect.
