feasibility-checklisted

# Feasibility Check Optimism is not a plan. Before a project is greenlit, find the thing most likely to kill it — and decide honestly whether it's achievable. ## When to use - Before committing to a project or initiative (the go/no-go moment). - When feasibility is genuinely uncertain — new tech, hard constraints, unknown data. - **Skip** when the path is well-trodden and the risk is obviously low. ## Procedure 1. **List the hard constraints:** time, team, budget, tech, data, external dependencies, compliance. 2. **Find the killer risks:** the assumptions that, if false, sink the project. Rank them by likelihood × how fatal. 3. **Reduce the top unknowns cheaply** — usually a small spike (see `prototyping`), not more discussion. 4. **Give a verdict:** go / no-go / go-if (with the conditions that must hold). A no-go now is far cheaper than a failure later. 5. **Write the `## Feasibility` section** of the project brief: constraints, top risks, the verdict and its conditions. ## Common mistakes - Greenlighting on optimism — no named risks means you didn't look. - Treating "we'll figure it out" as feasibility — name what would make it *infeasible*. - Endless analysis instead of a cheap spike to kill the biggest unknown. - Skipping Option Zero — the cheapest path is sometimes to not build it: an existing tool, a config change, or a smaller change to the problem. Rule it out before greenlighting a build.