Projects that never got approved and now have ROI in weeks

Every organization has a list. Projects that everyone knows would deliver value, but that never make it from the PowerPoint to the budget. AI has changed the denominator of that equation, and those projects no longer have an excuse.

It’s not a problem of ideas. In almost any organization with more than fifty people, there’s an unwritten list of projects that have been waiting for years. Automations that would save hours every week. Internal tools the team keeps requesting that never arrive. Manual processes that nobody has had the courage to calculate in real dollar terms.

The reason they never get executed is always the same: the cost of building them didn’t justify the return. Custom development required months of work and a budget that the board wasn’t willing to approve without certainty of a return in 18 to 24 months.

That calculation is no longer valid. Artificial intelligence has drastically compressed both the cost and the validation time. And that changes which projects deserve to be in the backlog — and which ones deserve to be executed now.

Why “good” projects didn’t get approved

The paralysis wasn’t irrational. It was a logical response to a specific cost structure. For years, developing custom software had three characteristics that made it hard to justify for moderate-impact projects:

• Fixed cost, variable value. Development cost was high and fixed, regardless of the project’s value. A process that saved 10 hours a week cost almost the same as one that saved 100.
• Long payback period. The recovery period was calculated at 18 to 24 months. Too much risk for projects that weren’t first-tier strategic priorities, and too much for most boards of directors.
• The self-perpetuating cycle. Year after year, the same projects appeared on the “priorities for next fiscal year” list. And year after year, they went back in the drawer. The accumulated opportunity cost was never accounted for.

The real problem wasn’t the cost of unexecuted projects. It was the accumulated cost of maintaining inefficient processes for years, multiplied by the number of people involved. That number rarely appeared in the budget analysis.

What has changed exactly?

The emergence of advanced language models and AI-assisted development tools is not an incremental change. It’s a break in the cost-return curve that directly affects the project approval equation.

But the most important figure isn’t the savings in development. It’s the change in perceived risk. Before, approving a project meant committing the entire budget before knowing whether it would work. Now, you can build a functional pilot in two weeks, measure the real impact, and decide whether to scale — with data, not assumptions.

The cost of being wrong has been reduced so much that the question is no longer whether it has ROI, but why it isn’t being executed yet.

This doesn’t mean every project makes sense now. It means the profitability threshold required to approve a project has structurally declined, and many projects that previously didn’t clear that bar now do.

Three types of projects to reconsider now

Not all drawer projects are equally recoverable. Three categories concentrate the greatest potential for fast returns:

1. Processes “that have always been done manually.” Workflows nobody has questioned because they’ve always worked that way. Manual contract review, support ticket categorization, briefing preparation for meetings. The cost has never been calculated in real terms because there was never an economically viable alternative. Now there is.
2. High human-consumption internal automations. Repetitive tasks that consumed hours of valuable people’s time but didn’t justify a formal project. Report consolidation, request classification, standard response generation, data extraction from documents. Individually, each task seems minor. Added together, they represent dozens of weekly hours of highly skilled work spent on low-skilled work.
3. Proprietary tools that IT never had time to build. Internal applications the team has been requesting for years: search tools over internal documentation, onboarding assistants, real-time status dashboards. Projects that always lost out to urgent maintenance priorities. With AI assisting in development, the time needed to build them has been reduced to a fraction of what was previously required.

How to evaluate whether a stalled project now has ROI

No forty-page business case required. The initial analysis can be done in under an hour with three concrete questions.

Warning signals: when to execute without further analysis

→ Does your team spend more than one day a week on a repetitive task? It probably has positive ROI with AI.

→ Does the process involve extracting, classifying, or summarizing information from documents or systems? The automation potential is almost certainly very high.

→ Is the answer to “why is it done this way?” simply “it’s always been done this way”? Calculate the real cost before assuming there’s no alternative.

→ If the project has been in the backlog for more than two years, the accumulated cost of not having executed it almost certainly already exceeds the current development cost.

The recommendation isn’t to approve all drawer projects at once. It’s to review the list with the new cost structure in mind, identify the two or three projects with the highest impact-to-effort ratio, and launch a two-week pilot. The pilot delivers the real answer — not an estimate, but actual usage data, adoption speed, and measurable savings.

The risk of being wrong is now low enough that the cost of prolonged analysis exceeds the cost of simply trying.

Frequently Asked Questions

What’s the difference between traditional automation and AI automation? Traditional automation (RPA, scripts) requires the process to be perfectly structured and predictable: if the format changes, the automation breaks. AI automation can handle variability, natural language, unstructured documents, and even make contextual decisions. This enormously expands the range of automatable tasks — and eliminates the maintenance friction that made many RPA automations more expensive to maintain than the manual process itself.

What does a two-week pilot actually cost? It depends on scope, but the ranges have changed substantially. Projects that two years ago required between €80,000 and €150,000 in initial development can today be validated with functional pilots for between €8,000 and €25,000. That’s the inflection point: the pilot no longer requires committing the full budget. If the pilot doesn’t demonstrate sufficient ROI, the cost of having tried is an order of magnitude lower than the cost of having fully developed it without prior validation.

What if the project requires integration with legacy systems? Legacy system integration remains the factor that most delays projects — that hasn’t changed. However, there’s an important distinction: many drawer projects don’t require deep integration into systems of record. They can operate on outputs from those systems (files, exports, emails) without needing API access. For those that do require integration, the pilot-first approach with sample data remains valid for validating impact before undertaking full integration.

How do I convince the board to approve a project when ROI isn’t guaranteed? The reframing is key: you’re not asking to approve the project, you’re asking to approve the pilot. The difference isn’t semantic — it’s budgetary. A two-week pilot requires a small spending approval, with a measurable success criterion and an explicit continuation decision at the end. That format drastically reduces approval friction. If the pilot demonstrates the expected ROI, full project approval arrives with real data, not PowerPoint projections.

How do you prioritize which backlog projects to review first? The simplest matrix crosses two variables: task frequency (how many times it occurs per week) and degree of structure (how predictable and standardized the process is). Projects with high frequency and a reasonably structured process have the greatest potential for fast ROI and lower implementation complexity. High-frequency but highly unstructured ones require more investment in design. Low-frequency projects rarely justify the effort, unless the impact per occurrence is exceptionally high.

Does the IT team need new capabilities to execute these projects? It depends on the starting point. Lower-complexity projects — automations over document workflows or API integrations with language models — can be executed by an intermediate development team with access to the right models. More complex projects, especially those requiring fine-tuning, RAG over proprietary knowledge bases, or integration with data infrastructure, do require specialized profiles. The practical recommendation is to start with projects the current team can execute, and use those first results to justify investment in additional capabilities.

Do you have projects in the drawer that could have ROI with AI? Tell us about your case. In a 30-minute call, we’ll help you identify which ones have the most potential and how to validate them.