# Delaying a tech project has a cost. How much? > Putting a tech project on hold is not free. The problem bills you every month and the workarounds grow. Here is how to price the wait in your business case. - Author: Marlon Trettin - Published: 2026-10-19 ยท Updated: 2026-10-19 - Language: en - Canonical: https://yowpi.com/en/blog/delaying-a-tech-project-has-a-cost --- Putting a tech project on hold is not the option that costs nothing. While the board waits, the problem keeps billing you every month, and the operation builds workarounds around it that will make the project bigger when it finally starts. The business case that gets approved puts the price of one month of waiting next to the price of doing. ## TL;DR - In August 2026, the NFIB small business Uncertainty Index stood at 89, [well above its historical average of 68](https://www.nfib.com/wp-content/uploads/2026/09/NFIB-SBET-Report-August-2026.pdf), and only 12% of owners said it was a good time to expand. "Let's revisit next year" is the easy answer right now. - In a Gartner survey of 151 supply chain leaders, [72% had reopened a final approval at least once](https://www.gartner.com/en/newsroom/press-releases/2026-07-14-gartner-survey-shows-72-percent-of-supply-chain-leaders-revisit-final-approvals-for-network-decisions-at-least-once-causing-delays), and more than half had done it three or more times. - The cost of delay is not linear. Every month of waiting adds lost hours, plus parallel spreadsheets and improvised integrations that later become migration scope. - Waiting is a legitimate decision when it buys information that could change the choice, with a date for that information to arrive. Without a question and a date, it is drift. ## Why does "not now" feel like the safe option? Because the cost of the project has an owner and the cost of waiting does not. The project reaches the board with a number, a timeline and someone who signs for it. The status quo arrives with none of that, so in the comparison it counts as zero. The current climate reinforces that bias. In the same NFIB report, based on 476 responses, only 24% of owners plan capital outlays in the next six months, and both actual and planned capital spending sit below their historical averages. With sales softer and costs up, deferring feels prudent. It feels that way, but the bill is real. In a West Monroe survey of 214 executives and 1,000 managers at US companies with at least $250 million in annual revenue, [73% estimate they lose up to 5% of annual revenue to slow decisions and execution](https://www.westmonroe.com/press-releases/slow-decisions-are-costing-companies-millions). The figure is the respondents' own estimate, published by a consulting firm that sells speed, so read it as an order of magnitude. The point for you is different: almost nobody writes that cost down. ## What keeps costing while the decision waits? The first layer is the recurring cost of the problem: the hours of manual reconciliation and the rework they fail to prevent. If you have already built the baseline [the way the board accepts it](/en/blog/justify-technology-investment-to-the-board), that number is ready. Read it per month instead of per year. The second layer rarely shows up: the workaround that grows. The operation does not stop working because the project stopped. Someone builds a spreadsheet to track what the system does not track, another department subscribes to a tool on its own, an analyst sets up an automation only they understand. It is the same mechanism as [shadow IT](/en/blog/shadow-it-when-every-department-picks-a-tool), now with no deadline to stop growing. Each of those workarounds is improvised architecture. It has its own data and its own rules, and usually only one person knows how it works. When the project is finally approved, all of it has to be discovered, cleaned and migrated. The project a year from now is not the same project as today. It is larger. The third layer is the external window. It might be a vendor contract that auto-renews, or the peak season when nobody can stop to implement anything. Once the date passes, the project costs more or delivers less, and nobody recorded that the wait charged for it. ## How do you put the cost of delay into the business case? With a monthly figure, not an ROI. Boards distrust projected returns, but they understand an expense that is already happening. The question the document answers is simple: how much does each month cost while the answer stays "not now"? Build the line from what you can measure today. The recurring cost comes from the baseline. You estimate workaround growth by counting what appeared in the last six months: new spreadsheets, tools bought outside the IT budget, parallel controls. The external window goes in as a date, with what changes after it. Gartner recommends something similar for supply chain network decisions. In the same research, the guidance is to include [the cost of day-to-day turbulence in the business case from the start](https://www.gartner.com/en/newsroom/press-releases/2026-07-14-gartner-survey-shows-72-percent-of-supply-chain-leaders-revisit-final-approvals-for-network-decisions-at-least-once-causing-delays), not only the costs of the investment itself. The field is different, but the mistake is the same: the document compares the project with a status quo that looks still and is in fact billing. ## When is waiting the right call? When the wait buys information that could change the choice. A rule that has not been published yet, for example, or a volume that still needs to be confirmed. In those cases, deferring is a decision, as long as it comes with the question written down and the date it will be answered. The same Gartner release notes that revisiting a decision is not a failure in itself, and that being able to stop, reverse or repurpose an investment prevents larger losses. That cuts both ways. A project designed in phases, with clear exits, removes the board's fear of signing something irreversible, and that fear is usually what sits behind "not now". The logic is the same as [setting the shutdown criteria before you start](/en/blog/when-to-shut-down-an-innovation-project). What does not hold up is a delay with no question attached. If nobody knows what information is missing, the next meeting will have the same data and the same answer. Meanwhile, the bill from the previous section keeps running. ## An example of how the math changes The scenario below is hypothetical, and the numbers illustrate the method rather than report a measurement. Picture a network of six clinics where reconciling claims between the scheduling system and billing is done by hand. The innovation manager proposes integrating the two. The board says the timing is bad and asks to revisit in twelve months. She comes back with three lines. Reconciliation takes about 120 hours a month from the admin team, which at a fully loaded $45 an hour comes to $5,400 a month. Over the last six months, the clinics created four parallel tracking spreadsheets, each with different rules, all of which would enter the migration scope. And the scheduling system contract renews in March, locking in another year. The proposal changes shape. Instead of asking for the whole project, she asks for the first phase: map the flow and integrate the highest-volume step before March. The rest depends on the outcome of that phase, with a review date. The board can still say no. Now it says no knowing what each month costs. A real case shows where this kind of control tends to live. Before [Reatop](/en/cases/reatop), the platform Yowpi built for Bumerangue, hospital waste tracking relied on spreadsheets and paper notes, and data consolidation arrived late. With the system, paper left the weighing and collection points, and more than 5,000 tons of waste are now tracked every month. Spreadsheet controls rarely come from an architecture decision. They fill the space the decision leaves empty. ## Frequently asked questions **How do I justify the investment when the board says now is not the time?** Do not argue about timing. Show what each month of waiting costs and what the wait would buy. If the wait brings no new information, the case for deferring weakens on its own. If it does, agree on the date that information arrives and come back with it. **What if I cannot measure the cost of the problem precisely?** Use ranges instead of a single number and state where each estimate comes from. Boards accept declared uncertainty more easily than invented precision. What they do not accept is a document where the cost of the status quo is missing. **Won't the implementation take too much of the team's time right now?** It will take some time, and that time belongs in the business case. But the team is already spending hours on the problem and on the workarounds around it. A short first phase, focused on the highest-volume step, can give some of those hours back before the larger effort begins. ## The next step If your proposal is stuck at "not now" and you want to know what the wait is already costing, the Operational Architecture Diagnostic is a 30-minute conversation to look at that math with you and point out where to start: [book it through our contact page](/en/contact).