A Stalled .NET Project Is Waiting on a Decision
Projects rarely stall because the team cannot write code. They stall because nobody can name the next decision, and activity fills the gap.
A stalled .NET project rarely stalls because the team cannot write code. It stalls because nobody can name the next decision.
Activity is not progress
Code is rarely the bottleneck in a project that has stopped moving.
The bottleneck is usually a decision that nobody owns: which workflow to migrate first, whether the old report still matters, who signs off on the data model, or what "done" means for the next release.
When the decision is unclear, the team fills the gap with activity. More tickets, more meetings, more refactoring. The project looks busy and stays stuck. Nobody is being lazy. The team is working hard on the parts of the problem that do not require a decision, because those are the only parts that are safe to touch.
Write the decisions down
The first useful move is to write down the next three decisions, the owner of each, and the date it needs to be made. Then remove every task that does not depend on those decisions.
- Decision. One sentence, written as a question a person can answer.
- Owner. A person, not a team.
- Date. The day it must be made, not the sprint it lives in.
- Consequence. What becomes possible the day after it is answered.
That last line matters. A decision with no consequence is a status update.
Why this works
A stalled project usually has enough engineers and not enough authority. The people closest to the code can see the options, but they cannot choose one, so they keep every option open. Keeping options open is expensive. It means parallel branches, half-migrated schemas, feature flags nobody removes, and two ways to do the same thing.
Naming the decision moves the cost from the team to the person who should be paying it.
What it looks like in practice
On a legacy modernization that has lost momentum, the list is often:
- Which workflow carries enough revenue to be migrated first.
- Whether the current data model is being kept or replaced.
- Who owns the business rules that only exist in the old code.
- What the team is allowed to stop maintaining.
None of those are coding tasks. All of them change what gets coded next.
This is not project management theater. It changes what the team works on tomorrow. It also gives you an honest read on whether the project is stuck on engineering or stuck on authority, and those two problems need very different fixes.
What is the next decision your project is waiting for, and who owns it?
This was published first as Dispatches from the Workshop.
Subscribe on LinkedIn