Method and decision making
The order of things: how good tech decisions actually get made
Most organisations never choose the order of their tech decisions - the vendor's sales calendar chooses it for them. Six steps that fail safely, and why deciding what deserves to be built comes before everything else.
By Arvind Eshwarlal · 21-10-2026 · 7-min read
Every tech decision has an order. The trouble is that most organisations never choose theirs - the vendor's sales calendar chooses it for them. A demo lands in the inbox. The demo is impressive. A quote follows the demo. Somewhere around the third follow-up call, the organisation is choosing between two plans for software that will run its programmes for the next five years - and not one question has been asked in the field where that software is supposed to live.
I want to lay out the order that has held up across five products and more than a decade in the social sector - the sequence we now run for every engagement. It isn't clever. Its only virtue is that it works, and that it fails safely: followed honestly, it sometimes ends with don't build, and that answer is worth more than any platform I could sell you. Sometime ago, I wrote that the hard part was never the building. This is the procedure for the part that is - deciding what deserves to be built at all. Six steps, and the order is the argument.
The six steps
Step 1
Start on the ground
Before anything else, go to where the work happens and understand the field reality. How does the current process actually run - not the one in the manual, the one that survives when the manual is ignored? What do people believe about records, about who is allowed to change data, about what counts as "official"? And the physical facts no proposal ever mentions: internet that drops for hours, electricity that arrives in the evening, a room so cramped there is no desk, dust that kills a tablet in a season, heat, rain, a phone shared by three coordinators. None of this is a footnote. The field is the specification. Any tool designed in a meeting room carries the meeting room's assumptions - desks, bandwidth, time - and the field will collect that debt with interest.
Step 2
Then listen to the team
The team is the user. The funder is not; the board is not. So before writing a single requirement, listen - for their skills (what can they already do, what training load is realistic), their limitations (language, numeracy, time, device access), their prejudices (which they've earned: most have survived a "digital transformation" before, and the memory of the abandoned app is data, not attitude), and their struggles (the hours that leak away every week into chasing, re-entering, printing). The team already knows exactly where the process breaks. Skip this step and you will get compliance during training and abandonment after - polite usage in front of the supervisor, and the old register running underneath.
Step 3
Then name the change components
Only now - with the ground truth and the team truth in hand - do you name what should change. Not "digital transformation"; components. A component is small and specific: attendance captured once instead of three times; reports generated instead of stitched; a parent update that doesn't cost one phone call per child. Each component earns its place by promising one of four things - improve the work, bring efficiency, ease a process, or give time back. Write this list before you look at any product. If a vendor helps you write it, every problem will look like their product.
Step 4
Then measure the outcome, and weigh cost-effort-benefit
For each component, ask what outcome it produces and what it truly costs - money, effort, disruption. Be unsentimental: some components fail this test, and when they fail, the test is working. Read the ledger honestly while you're at it - count time after implementation and adoption, against the process it replaced; some tools pay in lumps, not daily wages, in audits that never become fire-drills. I wrote more about that here.
Step 5
Now - and only now - the roadmap: build, buy or skip
With components weighed, the decision space finally opens. Build when the workflow is genuinely yours and no product will ever fit it. Buy when it's a solved problem and configuration beats construction. Skip when a spreadsheet is doing the job fine - the most profitable sentence in this entire sequence is "you don't need this yet." The roadmap that comes out of this is not a shopping list; it's a sequence with a budget: what happens first, what waits, what never happens, and what each step costs. Most organisations start here, at step five, with the decision. That is the whole error. A roadmap built without steps one to four underneath it is a guess with formatting.
Step 6
Then plan the after: implementation, training, adoption
The roadmap is the middle of the work, not the end of it. Implementation is change management, not installation - the process changes shape, and someone's routine changes with it. Training is scheduled around field reality, not around the calendar of whoever is delivering it. And adoption is the real test: does the team open it on a wet Tuesday without being asked? Budget for the dip, too - the first quarter is negative by construction, as training, migration and data cleanup all spend time before any comes back. Organisations that quit at day ninety abandon their tools at the exact moment before payback begins.
None of the six steps is difficult. What's difficult is keeping them in order - because every step done out of order produces a confident, well-formatted wrong answer. The ground keeps the assumptions honest. The team keeps the design honest. The components keep the scope honest. The ledger keeps the money honest. The roadmap turns all of it into one page. And then, and only then, the building begins - on the thing that survived the order.
A roadmap built without steps one to four underneath it is a guess with formatting.
That's the whole method. It's why our engagements start with a two-week roadmap and not a contract to build - sometimes it ends with buy instead of build, and once in a while with skip, which saves an organisation more money than any platform ever will.
If you want to know where your organisation stands before starting the sequence, our 18-question Tech Readiness Checklist score you on the same ground this method stands on - about six minutes, and an honest answer either way: Paper Cliff, Patchwork, or Build-Ready. Take the checklist.
Arvind Eshwarlal is the founder of Communittii. He has spent over a decade inside India's social sector - education, livelihoods, safe drinking water - and fifteen years building companies and products, with senior stints at Akamai, LinkedIn, and Gloat along the way.
Before you spend a rupee on software
Take the 5-minute Tech Readiness Checklist - or talk it through with us first. The call is free, and honest even if we never work together.