The stall is usually not the compiler
Most stalled custom projects we are asked to look at still compile. Screens exist. Someone can log in on a laptop in the meeting room. The stall happened earlier: the list of what “done” meant grew every week, nobody on the business side owned Tuesday, the old spreadsheet never ran beside the new numbers, and a festival date was treated as a plan. By the time the team talks about “the technical issues”, they are talking about the wreckage, not the cause.
This is a post-mortem you can run without naming a vendor or inventing a hero. It is also a brief for the next attempt. If you are still choosing who should build that attempt, that work lives on a different page — how to choose a software development company — and this article will not rewrite it. Here we only ask why the last job stopped moving, and what you must write down before anyone opens Visual Studio again.
Scope grew because the out-list was a rumour
The first week had a sentence: staff will record dispatches here instead of WhatsApp. By week four the sentence had a customer portal, last year’s reports, a driver app, and “the same thing for the second branch”. Nobody voted. Items arrived in standups and stayed. An MVP with a growing first list is a full project in denial. The stall is not mysterious. You cannot hit a date you never re-baselined while the list grew.
Write two lists before the next kickoff: in, and out. If a director adds an item to the first list, something else leaves, or the date moves, or you stop calling it the first slice. Doing that in email in week one is kinder than doing it in a demo in week ten, when the warehouse already hates the login and accounts have stopped coming to the calls.
Scope also grows in the gaps you refused to name. “Integrations TBC” is not a placeholder. It is a second project hiding in the first. Tally, the payment gateway, the SMS DLT templates, the weighbridge, the old item codes — either they are in the slice or they are out. A sentence that says “we will connect later” without a later date is how the slice becomes the programme, and the programme becomes a stall.
- In-list items have a user, a Tuesday job, and a way to undo a mistake.
- Out-list items have a name, so they cannot sneak back as “just a small screen”.
- Assumptions are written. If the supplier file is dirty, that is on the page, not a surprise in week six.
Nobody owned the Tuesday
A project without a named business owner is a project that encodes guesses. The vendor can own the repository. They cannot own “what happens when the supplier is new” or “who tells the night shift the screen changed”. If that person does not exist — a real name, a day a week, the authority to say no to a director — the stall is already scheduled. You will pay the hours later, in rework, after three people discover they meant three different jobs.
Ownership is not a steering committee of eight. It is one operations lead who sits with the build, looks at the first real data, and introduces the people who will click it without you. If they cannot spare the hours, you are not ready to build. You are ready for a one-page brief and a pause. Hiring a vendor to guess your GST treatment is how you fund a second project that looks like the first.
The owner also owns the exception path. Happy-path demos do not stall projects. The stall arrives when a credit note, a partial dispatch, or a branch transfer has no screen and no person. Write the three exceptions that already happen every week. Assign them. If nobody will take them, do not start. Software cannot sit with a mess you have not named.
No parallel run, so the numbers were a demo
If the new system touches stock or money, the old sheet or Tally company must run beside it until someone finance trusts will sign that the numbers match. Skipping that to “save two weeks” is how you get a go-live that is actually a screenshot. Staff keep the spreadsheet. The new screens become a reporting skin. Then someone calls the project stalled, when in fact it went live in name and died in use.
A parallel run is not theatre. It is a dated window, a list of fields that must match, and a person who will look at the mismatches on Thursday. If you cannot name those three, you are not parallel-running. You are hoping. Hope is not a cutover. The first slice of a .NET operations system should be boring enough that the parallel run is possible: one path, real records, an export accounts already understand.
Teams skip the parallel run because the festival is close, or because the demo looked clean on dummy data. Dummy data does not have the item code that means two things, or the customer spelled three ways. The parallel run is where those show up. If you have never seen them, you have not tested the job. You have tested the happy path the vendor planted.
The festival date was not a plan
Onam, Diwali, year-end — a date that will not move is a constraint, not a scope. Treating it as both is how backups get cut, how training becomes a PDF in a shared drive, and how you ship without an undo. Calling that an MVP does not make it one. A scoped phase with a change log is respectable. A festival deadline that silently ate the boring parts is how the next Monday starts with a rollback story and a warehouse that has gone back to WhatsApp.
If the date cannot move, the list must. Write that sentence in the kickoff notes. If the list cannot shrink, the date must. If neither can move, you are not in a build. You are in a political meeting that will later be described as a software failure. The honest move is to say so in week one, while you can still keep the spreadsheet as the system of record and book a slice after the festival.
Festival pressure also produces fake certainty. “We will go live on the first” sounds like leadership. It is not a definition of done. Done is: today’s dispatches are in the system four days out of five, accounts can export, a mistake can be undone, and the old sheet is a check, not the job. If you cannot say those sentences, you do not have a date. You have a wish.
Write the post-mortem as four sentences
Do this on one page, with names, before you take vendor meetings for the restart. The page is the project. A slide deck about “lessons learned” is not.
- Scope. What was in the first sentence, what was in the last list, and who added the difference without moving the date.
- Owner. Who was supposed to sit with the build each week, and whether they actually had the hours and the authority to refuse work.
- Parallel run. Whether money or stock was ever checked against the old record by someone finance trusts — and for how many days.
- Date. Whether a festival or a board meeting was allowed to cut backups, undo, training, or the out-list.
If you cannot fill those four without arguing, you are not ready to restart. The argument is the work. Software will not settle it. A partner who offers to “just start building” while those sentences are blank is offering to encode the same stall.
How the next one should start
Start from the expensive assumption, not from a module list. “Warehouse staff will record dispatches in the system instead of WhatsApp” is a test. Twelve modules on a slide are not. Build only what that sentence requires: login, the job, today’s list, undo, an export. Host it. Put it on the phone the supervisor already has. Count, after two weeks without you in the room, how often the job still leaked to the chat group.
That shape is an MVP. It is allowed to look unimpressive. It is not allowed to be unmeasured. “They liked the colours” is a prototype review. “Dispatch notes are created in the system four days out of five” is a result. Only the second one tells you whether to fund the portal.
- One page: the job, the users, the other systems, what done looks like on a Tuesday.
- Two lists: in and out. Change control written before the first sprint.
- A named owner with hours, and a named person for exceptions after go-live.
- A parallel-run window if the slice touches stock or money.
- A date that is allowed to lose to the list, or a list that is allowed to lose to the date — never both held fixed in silence.
Week one is not screens. It is sitting with the people who do the job, photographing the spreadsheet and the WhatsApp group, and writing the definition of done so narrowly it feels rude. Week two is access: test company in Tally, a sample of real orders, the credentials someone has to request. Weeks after that are one vertical path on real records. If after a month you have only workshops and a Figma file, you do not have a restart. You have discovery that has not been named. Name it and pay discovery rates, or stop.
What to refuse in week one
- A fixed total before anyone has seen an export or the other systems.
- “We will just include it” as the change process.
- A go-live that skips parallel run because a festival is close.
- No named owner on your side, with the vendor “handling requirements”.
- Cutting undo, backups, or handover to look lean.
Those refusals are how the next project stays a project. They are not hostility. They are the difference between a slice you can learn from and a stall you will post-mortem again next July. If a stakeholder cannot accept them, you are not looking at a software problem. You are looking at a date and a wish.
A restart page you can send this week
Write: the assumption sentence; the in-list and the out-list; who will use it on Tuesday without you; who owns exceptions; which systems must talk; whether a parallel run is required; what you will count after two weeks; the date you will slip if the list grows. Attach one real example — a redacted dispatch, a messy item file, a week of the chat group. Send the same page to whoever you already trust, or to a shortlist if you are choosing again.
If the reply is a technology list and a module brochure, you have a brochure. If the reply restates your process, names Tally or the gateway, writes assumptions, and asks who sits with the build, you have a partner conversation. How you score that conversation is already written in the buyer’s checklist. Do not run that page as a second essay here. Use it. Then come back to these four sentences if the last job still haunts the room.
We build this shape of work as ASP.NET Core systems people log into and finish a job in — not as a theme with a plugin for “operations”. The stack is not the post-mortem. The lists, the owner, the parallel run, and the date are. Get those honest, and the next Monday can be a slice instead of another stall. If you cannot get them honest, keep the spreadsheet, keep Tally, and spend the summer on the one-page brief. That is cheaper than a second unfinished login.
A stall is information. It tells you the sentence was too wide, the owner was a committee, the numbers were never checked, or a festival was asked to do the work of a scope. Write which one. Then write the next sentence small enough that a warehouse supervisor can complete it on a phone, and an accounts lead can agree the export, without a war room. That is how the next one should not stall. Anything larger can wait until that sentence is true on a Tuesday when you are not in the building.