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?
Zoltan Kohary, MCIOBManaging Director| International Advisory & Consultancy || QUEST GLOBAL PARTNERSDubai, United Arab Emirates
This is a very real issue in construction. Temporary decisions are often necessary to keep the job moving, but the problem starts when everyone gets used to working around them and the original issue quietly disappears from view. I think the important part is not just recording the assumption, but also giving it an owner and a clear point at which it has to be resolved. Otherwise the project keeps building dependencies around something that was never meant to become permanent. Once several trades have moved on, the cost of going back can be far greater than the cost of stopping for the right decision in the first place.
...
1 reply by farshid adavi
Sep 27, 2026 2:20 AM
farshid adavi
...
Thank you, Zoltan. Your point about ownership and a clear resolution point captures an important part of the issue. In practice, temporary decisions are often unavoidable; the real risk begins when dependencies accumulate around them faster than the original issue is resolved. At that point, what started as a practical workaround can quietly become part of the project baseline. I think this is where disciplined ownership and a defined resolution point become essential—not to slow progress, but to preserve the project’s ability to reverse course while reversal is still affordable.
Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
Farshid, I think your distinction between the reasonableness of the original workaround and what subsequently develops around it is particularly important. A decision can remain defensible given what was known at the time, while the project's exposure changes as other commitments begin to depend on it.
That makes me wonder whether “Progress Debt” grows primarily with time. An unresolved assumption might remain open for weeks while still being relatively easy to reverse. Another might survive only a few days before procurement, installation or other decisions make reversal increasingly costly.
Perhaps the more important variable is therefore not how long we carry the unresolved issue, but how much dependency and commitment we allow to accumulate around it.
That would also change what we monitor. Alongside asking what remains unresolved, I would ask: What has subsequently been allowed to depend on it? What evidence should trigger reconsideration? And are we approaching a point where reversing course will require different authority, greater cost, or consequences that were not present when the original decision was made?
In that sense, the temporary workaround may not be the real debt. The debt may emerge as we progressively consume our future ability to change course.
...
1 reply by farshid adavi
Sep 28, 2026 2:15 AM
farshid adavi
...
Luis, I think you’ve highlighted an important extension of the idea. The risk may not be only that the original workaround remains unresolved, but that the project gradually builds new dependencies around it. Even if the workaround is eventually removed, those dependencies may remain and make returning to the original path difficult or costly. Perhaps this is where temporary workaround turns into something deeper than “unfinished business” — it begins to create path dependency. That adds another dimension to Progress Debt worth exploring. Thank you for raising it.
I think one of the most effective ways to prevent a temporary workaround from becoming a permanent constraint is to treat unresolved decisions as active items rather than simply documenting them and moving on. For me, that means establishing clear ownership, defining what information or condition is needed to close the issue, and setting a review point before the unresolved decision creates too many downstream dependencies. Visibility is important, but accountability and follow-through are what keep an issue from quietly becoming part of the project’s “normal.” I also think project teams should consider the cost of preserving flexibility. Moving forward may protect the schedule today, but if each subsequent activity builds on the same assumption, the project can gradually lose its ability to change direction without significant cost or disruption. The goal isn’t to eliminate uncertainty or stop progress whenever something is unresolved. It’s to make the uncertainty visible, understand what the project is carrying forward, and deliberately decide when it needs to be revisited. That balance between maintaining momentum and protecting future flexibility is an important part of effective project management.
...
1 reply by farshid adavi
Sep 27, 2026 2:22 AM
farshid adavi
...
Thank you, Genevia. I particularly appreciate your point about making uncertainty visible. Documentation alone does not protect a project if the underlying assumption is never revisited. In practice, one of the more subtle risks is that a temporary workaround can remain technically visible while becoming operationally invisible—people simply start planning around it. That is where I see another dimension of progress debt: not only the cost of future rework, but the gradual loss of optionality. The longer unresolved decisions accumulate dependencies, the narrower and more expensive the available choices become.
This is a very real issue in construction. Temporary decisions are often necessary to keep the job moving, but the problem starts when everyone gets used to working around them and the original issue quietly disappears from view. I think the important part is not just recording the assumption, but also giving it an owner and a clear point at which it has to be resolved. Otherwise the project keeps building dependencies around something that was never meant to become permanent. Once several trades have moved on, the cost of going back can be far greater than the cost of stopping for the right decision in the first place.
Thank you, Zoltan. Your point about ownership and a clear resolution point captures an important part of the issue. In practice, temporary decisions are often unavoidable; the real risk begins when dependencies accumulate around them faster than the original issue is resolved. At that point, what started as a practical workaround can quietly become part of the project baseline. I think this is where disciplined ownership and a defined resolution point become essential—not to slow progress, but to preserve the project’s ability to reverse course while reversal is still affordable. Saving Changes...
I think one of the most effective ways to prevent a temporary workaround from becoming a permanent constraint is to treat unresolved decisions as active items rather than simply documenting them and moving on. For me, that means establishing clear ownership, defining what information or condition is needed to close the issue, and setting a review point before the unresolved decision creates too many downstream dependencies. Visibility is important, but accountability and follow-through are what keep an issue from quietly becoming part of the project’s “normal.” I also think project teams should consider the cost of preserving flexibility. Moving forward may protect the schedule today, but if each subsequent activity builds on the same assumption, the project can gradually lose its ability to change direction without significant cost or disruption. The goal isn’t to eliminate uncertainty or stop progress whenever something is unresolved. It’s to make the uncertainty visible, understand what the project is carrying forward, and deliberately decide when it needs to be revisited. That balance between maintaining momentum and protecting future flexibility is an important part of effective project management.
Thank you, Genevia. I particularly appreciate your point about making uncertainty visible. Documentation alone does not protect a project if the underlying assumption is never revisited. In practice, one of the more subtle risks is that a temporary workaround can remain technically visible while becoming operationally invisible—people simply start planning around it. That is where I see another dimension of progress debt: not only the cost of future rework, but the gradual loss of optionality. The longer unresolved decisions accumulate dependencies, the narrower and more expensive the available choices become. Saving Changes...
Saif ur RehmanProject Management| First NetGulf Company Limited
Thank you for this thoughtful post. "Progress Debt" is a very useful lens, and it matches what I have seen in construction and telecom infrastructure projects. Like financial debt, the real danger is not the principal but the interest that builds up quietly as more work depends on the unresolved item. A few practices that have helped me in practice: 1. Attach a "decision deadline" to every assumption, not just an owner. When we move forward on an unresolved issue, we identify the last responsible moment: the point where the first hard-to-reverse commitment will happen. That might be a purchase order, fabrication, a pour, or another discipline starting work. That date goes into the schedule as a milestone, so the assumption can't quietly outlive its expiry date. 2. Link assumptions to the activities that depend on them. Assumptions become dangerous when they are recorded in a log that nobody connects to the programme. Tagging dependent activities in the schedule makes it clear, in each review, how much work is now resting on something unresolved. When that list starts growing, it is an early warning. 3. Track the cost of reversing, not just the probability of being wrong. From a risk management view, I find it useful to ask: "What would it cost to change this decision today, and what will it cost next month?" If the cost curve is rising steeply, the issue needs escalation, even if the original workaround was sensible. 4. Protect the contract position from day one. In my contract management experience, many workarounds become permanent constraints through the paperwork rather than the engineering. An assumption made to keep progress going should be documented formally through RFIs, letters or meeting minutes, with a clear statement that it is provisional. Otherwise, when it later turns out to be wrong, the question of who pays for the change becomes a dispute instead of a straightforward variation. 5. Review "what we are building on" as a standing agenda item. I fully agree with your review question. We keep a short "open assumptions" section in progress reviews, showing each item's age, owner, decision deadline and number of dependent activities. Simply showing the age of an assumption often creates the urgency to resolve it.
In the end, I think the key word in your post is visibility. Temporary decisions don't become permanent constraints because people made bad choices. They become permanent because the decisions stop being discussed. Keeping them visible, owned and dated means moving forward with incomplete information stays a deliberate choice rather than an accident.
Thank you again for starting this discussion. I look forward to hearing other members' approaches.
...
1 reply by farshid adavi
Sep 28, 2026 2:18 AM
farshid adavi
...
Thank you, Saif. Your construction example captures a pattern that is very familiar in practice. A workaround rarely becomes difficult to reverse simply because time has passed. More often, decisions, dependencies, procurement, approvals, and ongoing activities gradually build around it, until reversing it carries a disproportionate cost or disruption. That is also why I see documentation alone as insufficient. A temporary workaround needs ownership, a review trigger, and clear closure criteria; otherwise, the project may continue moving while the decision quietly becomes embedded in the way the project operates. For me, this is an important part of Progress Debt: not only the unresolved issue itself, but also the accumulating cost and complexity of undoing what has been built around it. Your comment articulates that practical dimension very well. Thank you for adding to the discussion.
Farshid, I think your distinction between the reasonableness of the original workaround and what subsequently develops around it is particularly important. A decision can remain defensible given what was known at the time, while the project's exposure changes as other commitments begin to depend on it.
That makes me wonder whether “Progress Debt” grows primarily with time. An unresolved assumption might remain open for weeks while still being relatively easy to reverse. Another might survive only a few days before procurement, installation or other decisions make reversal increasingly costly.
Perhaps the more important variable is therefore not how long we carry the unresolved issue, but how much dependency and commitment we allow to accumulate around it.
That would also change what we monitor. Alongside asking what remains unresolved, I would ask: What has subsequently been allowed to depend on it? What evidence should trigger reconsideration? And are we approaching a point where reversing course will require different authority, greater cost, or consequences that were not present when the original decision was made?
In that sense, the temporary workaround may not be the real debt. The debt may emerge as we progressively consume our future ability to change course.
Luis, I think you’ve highlighted an important extension of the idea. The risk may not be only that the original workaround remains unresolved, but that the project gradually builds new dependencies around it. Even if the workaround is eventually removed, those dependencies may remain and make returning to the original path difficult or costly. Perhaps this is where temporary workaround turns into something deeper than “unfinished business” — it begins to create path dependency. That adds another dimension to Progress Debt worth exploring. Thank you for raising it.
...
1 reply by Luis Branco
Sep 28, 2026 5:04 AM
Luis Branco
...
Farshid, I think path dependency is a very useful direction in which to take the idea.
I would perhaps distinguish, though, between the accumulation of dependencies and path dependency itself. As commitments build around an unresolved condition, reversal may become more costly and the range of feasible future options may narrow. But that does not necessarily mean that the project has already become path dependent.
Path dependency may emerge when the trajectory begins to reinforce its own continuation, making subsequent choices increasingly conditioned by what has already been committed. Lock-in would be a stronger condition still.
That makes me wonder whether path dependency is not Progress Debt itself, but one possible mechanism through which what you describe as Progress Debt can become increasingly difficult to unwind.
If so, the concept may be less about returning to the original path than about preserving optionality: how much future room to manoeuvre are we consuming as we continue to build around something that remains unresolved?
That distinction could also make the lens more operational. We could monitor not only how long an issue remains unresolved, but what has become dependent on it, what commitments are becoming difficult to reverse, and which options are disappearing as a result.
Your reference to path dependency therefore adds an interesting next question for me: at what point does the accumulation of commitments around an unresolved condition stop merely constraining future options and begin to make the trajectory itself self-reinforcing?
Thank you for this thoughtful post. "Progress Debt" is a very useful lens, and it matches what I have seen in construction and telecom infrastructure projects. Like financial debt, the real danger is not the principal but the interest that builds up quietly as more work depends on the unresolved item. A few practices that have helped me in practice: 1. Attach a "decision deadline" to every assumption, not just an owner. When we move forward on an unresolved issue, we identify the last responsible moment: the point where the first hard-to-reverse commitment will happen. That might be a purchase order, fabrication, a pour, or another discipline starting work. That date goes into the schedule as a milestone, so the assumption can't quietly outlive its expiry date. 2. Link assumptions to the activities that depend on them. Assumptions become dangerous when they are recorded in a log that nobody connects to the programme. Tagging dependent activities in the schedule makes it clear, in each review, how much work is now resting on something unresolved. When that list starts growing, it is an early warning. 3. Track the cost of reversing, not just the probability of being wrong. From a risk management view, I find it useful to ask: "What would it cost to change this decision today, and what will it cost next month?" If the cost curve is rising steeply, the issue needs escalation, even if the original workaround was sensible. 4. Protect the contract position from day one. In my contract management experience, many workarounds become permanent constraints through the paperwork rather than the engineering. An assumption made to keep progress going should be documented formally through RFIs, letters or meeting minutes, with a clear statement that it is provisional. Otherwise, when it later turns out to be wrong, the question of who pays for the change becomes a dispute instead of a straightforward variation. 5. Review "what we are building on" as a standing agenda item. I fully agree with your review question. We keep a short "open assumptions" section in progress reviews, showing each item's age, owner, decision deadline and number of dependent activities. Simply showing the age of an assumption often creates the urgency to resolve it.
In the end, I think the key word in your post is visibility. Temporary decisions don't become permanent constraints because people made bad choices. They become permanent because the decisions stop being discussed. Keeping them visible, owned and dated means moving forward with incomplete information stays a deliberate choice rather than an accident.
Thank you again for starting this discussion. I look forward to hearing other members' approaches.
Thank you, Saif. Your construction example captures a pattern that is very familiar in practice. A workaround rarely becomes difficult to reverse simply because time has passed. More often, decisions, dependencies, procurement, approvals, and ongoing activities gradually build around it, until reversing it carries a disproportionate cost or disruption. That is also why I see documentation alone as insufficient. A temporary workaround needs ownership, a review trigger, and clear closure criteria; otherwise, the project may continue moving while the decision quietly becomes embedded in the way the project operates. For me, this is an important part of Progress Debt: not only the unresolved issue itself, but also the accumulating cost and complexity of undoing what has been built around it. Your comment articulates that practical dimension very well. Thank you for adding to the discussion. Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
Sep 28, 2026 2:15 AM
Replying to farshid adavi
...
Luis, I think you’ve highlighted an important extension of the idea. The risk may not be only that the original workaround remains unresolved, but that the project gradually builds new dependencies around it. Even if the workaround is eventually removed, those dependencies may remain and make returning to the original path difficult or costly. Perhaps this is where temporary workaround turns into something deeper than “unfinished business” — it begins to create path dependency. That adds another dimension to Progress Debt worth exploring. Thank you for raising it.
Farshid, I think path dependency is a very useful direction in which to take the idea.
I would perhaps distinguish, though, between the accumulation of dependencies and path dependency itself. As commitments build around an unresolved condition, reversal may become more costly and the range of feasible future options may narrow. But that does not necessarily mean that the project has already become path dependent.
Path dependency may emerge when the trajectory begins to reinforce its own continuation, making subsequent choices increasingly conditioned by what has already been committed. Lock-in would be a stronger condition still.
That makes me wonder whether path dependency is not Progress Debt itself, but one possible mechanism through which what you describe as Progress Debt can become increasingly difficult to unwind.
If so, the concept may be less about returning to the original path than about preserving optionality: how much future room to manoeuvre are we consuming as we continue to build around something that remains unresolved?
That distinction could also make the lens more operational. We could monitor not only how long an issue remains unresolved, but what has become dependent on it, what commitments are becoming difficult to reverse, and which options are disappearing as a result.
Your reference to path dependency therefore adds an interesting next question for me: at what point does the accumulation of commitments around an unresolved condition stop merely constraining future options and begin to make the trajectory itself self-reinforcing?
...
1 reply by farshid adavi
Sep 29, 2026 9:54 AM
farshid adavi
...
Luis, I think “future ability to change course” gets very close to the heart of it. Perhaps not everything we leave behind should be understood simply as debt. Debt assumes some possibility of repayment or recovery. But when continuing forward reduces the project’s future options, we may be losing something more fundamental: optionality. That makes me wonder whether the real question is not only “What are we accumulating as we move?” but also “What are we making impossible to recover later?” That distinction could change how we think about the cost of keeping a project moving.
Farshid, I think path dependency is a very useful direction in which to take the idea.
I would perhaps distinguish, though, between the accumulation of dependencies and path dependency itself. As commitments build around an unresolved condition, reversal may become more costly and the range of feasible future options may narrow. But that does not necessarily mean that the project has already become path dependent.
Path dependency may emerge when the trajectory begins to reinforce its own continuation, making subsequent choices increasingly conditioned by what has already been committed. Lock-in would be a stronger condition still.
That makes me wonder whether path dependency is not Progress Debt itself, but one possible mechanism through which what you describe as Progress Debt can become increasingly difficult to unwind.
If so, the concept may be less about returning to the original path than about preserving optionality: how much future room to manoeuvre are we consuming as we continue to build around something that remains unresolved?
That distinction could also make the lens more operational. We could monitor not only how long an issue remains unresolved, but what has become dependent on it, what commitments are becoming difficult to reverse, and which options are disappearing as a result.
Your reference to path dependency therefore adds an interesting next question for me: at what point does the accumulation of commitments around an unresolved condition stop merely constraining future options and begin to make the trajectory itself self-reinforcing?
Luis, I think “future ability to change course” gets very close to the heart of it. Perhaps not everything we leave behind should be understood simply as debt. Debt assumes some possibility of repayment or recovery. But when continuing forward reduces the project’s future options, we may be losing something more fundamental: optionality. That makes me wonder whether the real question is not only “What are we accumulating as we move?” but also “What are we making impossible to recover later?” That distinction could change how we think about the cost of keeping a project moving. Saving Changes...
