Most transformation efforts do not fail at the hard part. They fail before it. A company decides to modernise, gathers a committee, drafts a multi-year roadmap, and then spends months refining that roadmap until the energy drains out of the room. Nothing ships. Nothing gets tested. And the organisation slowly concludes that transformation is a theoretical exercise.
The way out is not a better plan. It is a smaller first step, chosen well. One project that is narrow enough to finish, visible enough to matter, and useful enough to prove that change is possible. This article is about how to pick that project and how to know it worked.
Why big plans stall before they start
Large plans feel responsible. They signal seriousness, and they give leadership something to approve. The trouble is that a plan covering the whole journey has to account for everything at once: every team, every system, every dependency, every exception. That is an enormous amount of uncertainty to resolve before anyone has learned anything real.
So the plan grows. Each review adds a caveat. Each caveat invites another meeting. Meanwhile the people who will actually do the work are waiting for clarity that never quite arrives, and the problems the transformation was meant to solve keep getting worse.
There is a second, quieter reason plans stall. A big plan has no natural moment of completion. When does a three-year roadmap count as done? Nobody can say, so nobody can celebrate, and nobody can point to proof. Without proof, the next budget conversation becomes an argument about faith rather than evidence.
Worth remembering: a plan is a prediction, and predictions get more reliable after you have tested one small piece of reality. Sequence matters more than scope.
This is where a first project earns its keep. It converts an abstract commitment into a concrete result, and a concrete result is something an organisation can build on.
Three criteria for choosing a first project
Not every small project is a good first project. Some are small because they are trivial. Others are small but sit inside a political minefield. The right candidate usually clears three tests at once.
It is narrow enough to finish
Pick something with a clear boundary and a short horizon. A process handled by one team, a recurring report that takes too long to produce, a handoff between two departments that keeps losing information. The scope should be small enough that you can describe the finished state in a sentence and roughly guess when you will get there.
Resist the temptation to make the first project impressive. Impressive usually means broad, and broad means months of coordination before anything is visible. Narrow wins.
It is visible enough to matter
A finished project that nobody notices teaches nobody anything. Choose work that touches a pain people already feel: the queue that backs up every month, the spreadsheet three people maintain by hand, the approval that takes a week for no clear reason. When that pain eases, the organisation notices without a slide deck explaining why it should care.
Visibility also creates honest feedback. If the improvement is real, people say so. If it is not, they say that too, and you learn early while the cost of changing course is still low.
It is safe enough to learn from
Your first project should not be the one where a mistake becomes a regulatory incident or a customer-facing outage. You want room to be wrong. Pick something where a partial result is still better than the current state, and where a failed attempt produces information rather than damage.
This is a trade-off, and it is worth naming: the safest projects are often the least exciting, and the most exciting projects are often the least safe. The first project should lean toward safe, because its job is to build confidence, not to be the highlight of the year.
Signals that a process is ready to modernise
Once you have a shortlist, look for signs that a process is genuinely ready for change rather than merely annoying. Readiness is not the same as pain. Some painful processes are painful because of a decision nobody wants to make, and no amount of modernisation will fix that.
- It is repetitive and rule-based. The same steps happen in the same order, and the rules are written down somewhere, even informally. Rules can be examined, and examined rules can be improved.
- People work around it. You find side spreadsheets, private trackers, or a shared inbox acting as an unofficial system. Workarounds are a strong signal that the official process is failing the people inside it.
- The delay is measurable. Someone can tell you roughly how long a step takes and where it waits. If nobody can describe the current state, you are not ready to change it yet.
- Ownership is clear. One person or one team can say yes. Processes split across four owners with no final decision-maker tend to stall no matter how good the idea is.
- It touches a decision, not just a task. The best first projects improve how someone decides something, because decisions compound. Saving ten minutes of typing is nice. Getting an answer a day earlier changes behaviour.
If a candidate shows two or three of these signals, it is worth a closer look. If it shows none, put it back on the list and keep looking. That is not failure. That is selection working.
Defining success before you begin
Most projects drift because success was never defined in a way anyone could check. "Improve the process" is not a target. It is a mood. Before the first project starts, write down what a good outcome looks like in plain language, and agree on it with the people who will judge the result.
A useful success definition covers three things. First, the change itself: what will be different for the people doing the work. Second, the evidence: how you will know, using something you can observe without a debate. Third, the boundary: what you are deliberately not fixing in this round, so the scope does not quietly expand.
Keep the evidence simple. Cycle time for a request. Number of manual handoffs. How often the same information gets re-entered. You do not need a dashboard empire. You need one or two measures that a sceptical colleague would accept as fair.
It also helps to define what failure looks like, and to say out loud that a failed first project is survivable. Teams take better risks when they know the downside is a lesson rather than a career event. That permission is often the cheapest thing leadership can give.
Using early wins to fund the next step
A finished first project does two jobs. It solves the problem it was aimed at, and it changes the conversation about what comes next. Both matter, but the second is the one that keeps transformation alive.
When you report the result, lead with what changed for the people involved, then show the evidence you agreed on at the start. Be honest about what was harder than expected and what you would do differently. Credibility comes from that honesty, not from a flawless story. A team that admits a rough patch is far more persuasive than one that claims everything went smoothly.
Then use the win deliberately. The people who lived through the first project are your best argument for the second. They can describe the before and after in their own words, which carries more weight than any roadmap. Budget conversations get easier when the ask is "fund the next one like the last one" rather than "trust us for three years."
Choose the second project the same way you chose the first: narrow, visible, safe enough to learn from. Slightly more ambitious is fine. A sudden leap in scope is not. Momentum is built by a sequence of finished things, not by one heroic push followed by exhaustion.
This is the practical core of what smart digital transformation at low cost looks like at DevVina: start where the value is clear, keep the first step small enough to complete, and let evidence earn the next one.
The first step is a decision, not a plan
You do not need to know the whole journey. You need one project you can finish, a definition of success you can check, and the discipline to keep the scope small when someone suggests adding just one more thing. That is enough to move from deciding to transform to actually transforming.
Pick the candidate that clears the three criteria. Confirm the signals are there. Write down what success means before anyone starts building. Then finish it, report it honestly, and let the result make the case for the next step. Small, chosen well, beats grand every time.
