Institutional technology
5 min read
When the right answer is to wait
Recommending against a build is sometimes the most valuable thing a technology firm can do. The pressure to proceed is constant. The discipline to pause is rare.
The pressure to build is constant. Every brief implies urgency. Every deadline creates the sense that the window for action is closing. Every vendor proposal includes a clause about competitive timing.
In this environment, the recommendation to wait is the most professional and the least comfortable thing a technology adviser can offer.
Why waiting is hard to recommend
Recommending against a build requires the adviser to resist several pressures at once. The commercial pressure to proceed. The client's expectation of a deliverable. The internal pressure to justify a diagnostic engagement with something tangible at the end.
Most advisers proceed. The build happens. The problems surface. A second engagement is required to fix what the first one created.
Three situations where waiting is the right answer
The first is when the data is not ready. A system that requires structured historical data, whether for reporting, AI, or analysis, built before the data is structured will produce incorrect outputs. Waiting to build until the data architecture is in place is not delay. It is sequence.
The second is when the organisation is not aligned. A system that crosses departmental boundaries, changes workflows, or requires ownership decisions that have not been made will be resisted in implementation even if it was accepted in procurement. Building before alignment exists creates a technically complete system that no one uses.
The third is when the technology is changing faster than the deployment cycle. In periods of rapid technological change, a system specified today, built over six months, and deployed in a changing landscape may be obsolete at launch. Waiting for a period of relative stability, or building modularly so the system can adapt, is the more intelligent choice.
Three situations where waiting is correct
DATA NOT READY
The system requires structured historical data. Building before the data architecture is in place produces incorrect outputs from day one.
ORG NOT ALIGNED
The system crosses departmental boundaries or requires ownership decisions that have not been made. Adoption will fail even if procurement succeeds.
TECHNOLOGY CHANGING
The deployment cycle is longer than the stable window. Waiting for relative stability, or building modularly, is the more intelligent choice.
We will not build the wrong thing. That is the commitment. Waiting is sometimes how that commitment is kept.
What productive waiting looks like
Waiting is not inaction. It is preparation. Productive waiting means using the time to address the conditions that made building premature: cleaning and structuring data, resolving ownership questions, aligning stakeholders who will govern the system, and monitoring the technology landscape for the moment when the right architecture is clear.
Build now
Rarely costs just the project. Costs the next one too.
Build after
Lower total cost. Higher institutional confidence.
The cost of building too early
The direct cost of a failed system is measurable: the procurement cost, the implementation cost, the maintenance cost of something that does not work. The indirect cost is harder to measure but larger: the erosion of institutional confidence in technology investment, the political capital spent defending a failed system, the delay to the right solution caused by the existence of the wrong one.
Building too early rarely costs just the project. It costs the next one too.
Continue reading
←All insightsIf this resonates with a challenge you are navigating, we are happy to talk through it.
Start a conversation