One lesson I have learned from working on projects is that keeping the work moving is not always the difficult part. Knowing what we are leaving unresolved while doing so is much harder.
This happens frequently in construction.
A design interface is not completely resolved, but there is enough information to continue. A temporary technical solution keeps a work front open. Procurement proceeds based on an assumption because waiting would threaten the schedule. A decision is postponed because more information will become available later.
In many cases, I would make the same decision again.
Projects operate under uncertainty. Waiting until everything is fully resolved can be just as damaging as moving too quickly. Good project management therefore sometimes means deliberately moving forward with incomplete information.
But there is a second part to that decision that I think deserves more attention:
What happens to the unresolved issue after we move past it?
I have seen small assumptions become much larger problems not because the original decision was unreasonable, but because the project continued building around them.
- First, the assumption affects one activity.
- Then procurement depends on it.
- Then installation.
- Then another discipline.
- Eventually, something that was relatively easy to change becomes expensive and disruptive to reverse.
The issue was not necessarily the original workaround. The issue was the accumulation of dependency around something that was still unresolved.
I have started thinking about this as a kind of “Progress Debt.”
Not as a replacement for risk management, issue management, assumption tracking or decision logs. Those disciplines already give us established ways to manage uncertainty.I use the term more as a practical lens: a reminder that sometimes we maintain today's progress by carrying unresolved decisions into tomorrow. And, like other forms of debt, the critical question may not be whether we have any. Complex projects probably always will.
The more useful question is:
How long can we carry it before it becomes expensive to reverse?
That distinction has become increasingly important to me. A temporary decision that remains visible, owned and reversible can be perfectly healthy. The same decision becomes very different once several downstream activities depend on it.
So in project reviews, alongside the familiar questions about schedule, cost, risks and progress, I increasingly find another question useful: What are we currently building on that we have not fully resolved yet?
Not necessarily to stop the work. Sometimes the right answer is still to continue. But at least we know what we are carrying forward — and where our future flexibility may begin to disappear. I am curious how others handle this in practice.
When you deliberately move forward with an unresolved issue, how do you make sure a temporary workaround does not quietly become a permanent project constraint?
