The Half-Built House: Why IT Projects Stall, and How to Get Them Moving Again

Most IT projects don't fail in one dramatic moment. They slow down. The demos still look good and the team is still busy, but launch day keeps moving. The money gets tighter and the people paying for it stop agreeing on what "done" means.

In this post we walk through a real kind of situation using a made-up example: LedgerLark, an AI-powered app that helps UK sole traders and landlords file their tax return through HMRC's Making Tax Digital (MTD) service. We look at why projects like this get stuck and the tools that get them moving: the house analogy, MoSCoW, a stakeholder vote, honest options and a firm deadline. We also cover how to use AI to bring non-technical stakeholders along.

Note: LedgerLark is a made-up name. The example is based on patterns we see again and again in software projects. Any match with a real product is by chance.

Where LedgerLark got stuck

On paper, LedgerLark was in great shape. Users could upload bank statements, and the app sorted transactions with rules first, then AI, then a human check. A chat assistant helped fill in income forms. Filing worked end to end in HMRC's sandbox (its practice system). The team had strong CI/CD, automated tests, backups and monitoring.

But it wasn't live. Here is why:

• Security work wasn't finished. The API gateway and web firewall were only on the test system, and no pen test had been booked.
• HMRC hadn't approved the app for production yet. Every route to filing real returns with software needs HMRC approval, so there's no shortcut.
• The AI chat assistant worked, but took close to a minute to answer.
• The iPhone app and payments hadn't started.
• Three equal owners each wanted something different, and nobody had committed money beyond the current month.
• Hosting, cloud and AI bills kept arriving every month, with no income yet.

The house analogy: one picture everyone understands

Engineers say things like "WAF is only on INT" or "MTD production credentials are pending". Business owners hear noise. So we drew the project as a house.

• Foundation and walls are the parts that are built: code, cloud, tests and the core app.
• A roof that's half on is security. You wouldn't let a family move in while rain still gets in.
• Bare rafters are HMRC live approval. The frame is up, but it isn't signed off.
• A hanging window is the AI assistant. It works, but it isn't finished.
• No front door means real users can't come in yet.
• The meter is running, so costs keep going whether you build or not.
• Owners with question marks and builders about to put their tools down show the real blocker: no shared plan and no committed budget.

The picture does one important job. It shows that "nearly finished" and "ready for people to live in" are two very different things. Non-technical stakeholders often see a working demo and think launch is one step away. The house shows them the roof and the front door.

Why projects like this derail

LedgerLark had all of the usual warning signs:

1. No shared "done". One owner wanted a quick launch, another wanted the full AI chat, and a third wanted the iPhone app. Everyone was right in their own head, and the team was pulled three ways.
2. Invisible work. Security, compliance, data protection and pen-test prep don't show up in a demo, so they feel optional to people who don't see them. They aren't optional.
3. Outside gates. HMRC reviews, Apple's App Store review and pen-test bookings take weeks that you don't control. Plans that ignore them always slip.
4. Funding one month at a time. When money is agreed month by month, every month turns into a fresh debate. The team spends energy on staying alive, not on finishing.
5. The meter keeps running. Four environments, GPU hosting and cloud registries all cost money even when nothing ships.
6. Small team, big upkeep. Two developers spent a lot of their week keeping tests and servers green rather than building toward launch.
7. No decision date. This is the most dangerous one. Without a date, "we'll talk about it next week" can go on for months.

A project rarely fails because the team can't build it. It fails because the people around it can't agree what to build, by when, and for how much.

Step 1: MoSCoW, for the situation and for the features

MoSCoW is a simple way to sort a long list into four groups: Must, Should, Could, Won't (for now). We used it twice: once for the situation, and once for the features.

The situation-level list was the eye-opener. Before any new feature, the Musts were: get a clear yes or no on funding by a set date, pay for work already done, keep users' data safe, and stop paying for things nobody uses. Writing these down took the heat out of the room, because they're hard to argue with.

Step 2: let every stakeholder vote

Next, we gave each owner the same list of 15 items with a rough effort estimate next to each one. Each owner marked every item M, S, C or W on their own. The rule was simple: an item is a Must if two of the three owners say so.

This does three things:

• It gives quieter stakeholders an equal voice.
• It shows where people already agree, which is often more than they expect.
• It puts a cost next to every wish. When an owner sees "Android app: 4+ weeks", it often moves from Must to Won't on its own.

Step 3: offer honest options with dates

Stakeholders can't choose between ideas. They can choose between options that have a time and a cost. We gave LedgerLark's owners three:

Option	What's in it	Rough time
A. Lean launch	Musts only: security, pen test, HMRC approval, data protection, cost cuts. Web only, free at first.	~4–5 weeks of work, plus the HMRC review
B. Peak-season launch	A, plus the AI assistant, payments and the App Store	~8–9 weeks, ready before the January tax deadline
C. Everything	B, plus the nice-to-haves	~13–15 weeks, which lands right on the deadline (risky)

Step 4: set a deadline, and make "stop" a safe answer

This is the step most teams skip, and it's the one that matters most. We set one clear rule: if every owner hasn't committed funding in writing by Friday at 4pm, development stops and we close down safely within four weeks.

A good exit plan isn't a threat. It's a safety net:

• Week 1, save: archive the code, back up the data and secrets, and collect handover notes.
• Week 2, switch off test: shut the test systems and revoke every API key.
• Week 3, switch off live: tell users, handle personal data properly under UK GDPR, and remove the servers.
• Week 4, confirm: check every bill shows zero. Keep the domains and code, so a restart is possible.

We also put one more thing in writing: every owner remains liable for their equal share of work already done, whatever they decide about new funding. Saying this early stops the hardest argument from happening late. (Always check the wording against your own shareholder agreement.)

Handling the objections you will hear

What a stakeholder says	A calm, honest answer
"It works in the demo. Why can't we just launch?"	"The walls are up, but there's no front door yet. Real users bring real money and real data. We need the security work and HMRC approval first."
"Why pay for security nobody can see?"	"It's the roof. You only notice it when it rains, and in a tax app, rain means leaked bank statements."
"Can't we use a simpler API and skip HMRC approval?"	"No. Every software route to file real returns needs HMRC sign-off. The fastest path is to finish the approval, not to go around it."
"AI writes code now. Why is this taking weeks?"	"AI speeds up building. It doesn't speed up HMRC reviews, Apple reviews or pen testers. Those waits are on the timeline for a reason."
"Let's add Android too."	"Happy to. It's about 4+ weeks. Shall we vote on it as a Must, or put it on the Won't-for-now list until after launch?"
"I didn't agree to pay for past work."	"That's why it's in writing now, before any new decision. Past work is shared. New funding is a separate choice."
"Let's decide next month."	"Every month without a decision costs us hosting and team time. Friday at 4pm gives everyone a week, and both answers are fine."

The best use of AI with non-technical stakeholders

AI was a big help on LedgerLark. It didn't make the decisions. It made the decisions easier to see. Here is what worked:

1. Turn activity into a progress report. AI read a month of team chat and merged pull requests and wrote a plain summary: what shipped, what got fixed, and what's still blocking launch. That took minutes, not a day.
2. Translate jargon. "Production credentials pending" becomes "the tax office must approve us before it's real". Same facts, words everyone understands.
3. Draw the picture. The house, the MoSCoW grid and the option timelines were all drafted with AI help, then checked by people.
4. Prepare for objections. Before the meeting, ask AI: "You're a non-technical shareholder who wants a fast, cheap launch. What will you push back on?" Then practise your answers.
5. Check the rules. AI helped research what HMRC actually requires for software filing, with links to the official guidance, so the conversation started from facts instead of guesses.
6. Draft the paperwork. The survey, the exit plan and the sign-off sheet were drafted quickly and then reviewed line by line.

Where to be careful:

• AI estimates are a first guess. Have the people doing the work check every number.
• Never paste secrets, passwords or customers' personal data into a chat tool.
• AI can write a clear summary. It can't build trust between owners. That still takes a real conversation.

The decisions that kept things moving

• Show, don't tell: one honest progress report and one picture, not a 40-slide deck.
• Separate the past from the future: agree how to settle work already done before debating new spend.
• Vote, with costs visible: each wish has a time next to it, and two out of three votes makes a Must.
• Give options, not opinions: A, B or C, each with weeks and outside waits.
• Set a date: a firm deadline, with "stop" as a safe and planned answer.
• Stop the meter: cut unused environments and services right away, whatever the decision.
• Protect users first: security and data protection stay on the Must list in every option.

A quick checklist for your own stuck project

1. Can you explain your project's status in one picture?
2. Do all stakeholders agree what "launched" means?
3. Is there a written Must list that everyone has voted on?
4. Does every option have a time, a cost and the outside waits?
5. Is there a decision date, and an exit plan if the answer is no?
6. Is it clear who pays for work already done?
7. Do you know what the project costs each month while you wait?

If you answered "no" to two or more, your project may be a half-built house. The good news is that the fix usually isn't more code. It's a clear plan that everyone signs.

LedgerLark is a made-up example used for illustration only. This article is general guidance, not legal or financial advice.