Consultant| Canarys Automation LtdBangalore, Karnataka, India
As project managers, we are trained to optimize—scope, quality, timelines, and outcomes. But in real-world projects, especially under constraints, pursuing perfection can sometimes delay value or increase risk.
In my experience, knowing when “good enough” is actually the right decision is a critical but under-discussed skill.
Discussion points:
How do you decide when to stop refining and start delivering?
What signals help you distinguish between acceptable quality and risky compromise?
How do you align stakeholders when expectations differ on “good enough”?
Looking forward to hearing how others navigate this judgment call in practice.
Program Manager| HARPER SRLSanto Domingo / Distrito Nacional, Dominican Republic
I would say when additional refinement no longer reduces risk or increases value. A few practical signals I watch for:
Changes are cosmetic, not outcome-shaping
Stakeholders can’t clearly articulate what extra benefit they expect
The cost of delay is starting to outweigh the benefit of improvement
The key is aligning upfront on minimum acceptable outcomes, not just quality standards. When everyone agrees on what must be true for the solution to work, “good enough” stops feeling like compromise and starts feeling like disciplined delivery. Saving Changes...
Senior IS Project Manager| Baycare Health SystemsClearwater, Fl, United States
Ashwin - Using Agile methodology you would often have a MVP (Minimal Viable Product) that would be delivered so that you can immediately provide value to the customers, with the understanding that additional enhancements will be provided in future sprints or releases. No need for the customers to wait for everything to be perfect to start realizing benefits! Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
“Good enough” becomes the right decision when it is consciously chosen, not when it is imposed by fatigue, pressure or wishful thinking.
In practice, I’ve found three signals particularly helpful.
First, reversibility. If the decision is easy to correct later, delivering earlier often accelerates learning and reduces overall risk. If it is hard to reverse, the quality bar must be deliberately higher.
Second, value flow. When additional refinement no longer changes stakeholder decisions, behaviour or outcomes, we are optimizing internally rather than creating external value. That is usually the moment to deliver.
Third, systemic risk. “Good enough” is acceptable when it reduces global risk, even if it leaves local imperfections. It becomes dangerous when it merely hides or shifts risk downstream.
Stakeholder alignment improves significantly when “good enough” is framed explicitly as a decision about value, risk and learning, not as a shortcut on quality. When that framing is clear, the conversation becomes strategic rather than emotional.
The real question, perhaps, is not whether something is “good enough”, but for whom, for how long, and at what systemic cost.
In the case of software and data projects that's probably a false dilemma. You can/should *continue* refining AND delivering - at least until something more important comes along. Software may never be finished until people decide to stop using it and throw it away.
Financial Management Specialist | US Peace CorpsYaounde, Centre, Cameroon
Jan 26, 2026 1:12 PM
Replying to Luis Branco
...
“Good enough” becomes the right decision when it is consciously chosen, not when it is imposed by fatigue, pressure or wishful thinking.
In practice, I’ve found three signals particularly helpful.
First, reversibility. If the decision is easy to correct later, delivering earlier often accelerates learning and reduces overall risk. If it is hard to reverse, the quality bar must be deliberately higher.
Second, value flow. When additional refinement no longer changes stakeholder decisions, behaviour or outcomes, we are optimizing internally rather than creating external value. That is usually the moment to deliver.
Third, systemic risk. “Good enough” is acceptable when it reduces global risk, even if it leaves local imperfections. It becomes dangerous when it merely hides or shifts risk downstream.
Stakeholder alignment improves significantly when “good enough” is framed explicitly as a decision about value, risk and learning, not as a shortcut on quality. When that framing is clear, the conversation becomes strategic rather than emotional.
The real question, perhaps, is not whether something is “good enough”, but for whom, for how long, and at what systemic cost.
“Good enough” is the right decision when a deliverable meets business objectives and key quality standards, and further refinement adds little value while risking delays or higher costs. Saving Changes...
I like how you frame this as a judgment skill, not a delivery shortcut.
In practice, I’ve found that “good enough” becomes the right decision when refinement stops changing the decisions that follow. If additional work improves internal confidence but doesn’t alter stakeholder choices, trade-offs, or risk posture, then we’re often optimizing the artifact rather than the outcome.
A few signals I watch for:
The remaining feedback is about how it looks or feels, not what it enables
Stakeholders struggle to articulate what new risk is actually being reduced
Delivery delay is starting to create second-order risk elsewhere (missed windows, deferred learning, erosion of trust)
What makes this hard isn’t quality—it’s alignment. Teams often debate “good enough” because they haven’t aligned on what must be true for the decision to be made. When that decision threshold is explicit, “good enough” stops feeling like compromise and starts functioning as disciplined execution.
For me, the real question isn’t is this good enough? It’s good enough to decide what—and for whom—right now?
That framing usually shifts the conversation from perfection vs speed to judgment vs avoidance. Saving Changes...
Deciding when to stop refining and start delivering is something you should be considering in the early stages of the project. There are two key pieces to this:
1. Project Scope
2. The triple constraint
Hear me out.
Anything beyond defined and approved scope is unnecessary refining. This assumes effective scope change management.
For most of my project management career, I've considered the triple constraint not as the iron triangle, but as an indicator of what the sponsor/customer values most. Once you're aware that you aren't going to be able to deliver on time, it's time to come up with options. If scope is more important to the sponsor/customer than cost or schedule... you know how it works. Having this perspective of the triple constraint, whether it is the original version or the agile version, is important because it's not our decision to make. We identify the situation, we provide options and explain trade-offs. We help make the decision informed and easier.
Ultimately, the triple constraint is a decision-making tool, and knowing who makes the decision is critical. I don't always try to align all stakeholders on "good enough"; unanimity, or something close to it, is only needed when dealing with a committee or board, and even then most will defer to a final decision-maker once their major concerns have been allayed. Alignment is a delivery ideal. Effective governance allows for managing disagreement safely and effective decision-making. Instead of chasing alignment, move forward, despite its absence, by clarifying authority, defining options, controlling narrative, and making decision-making easier for the decision-makers.
Product Operations Program ManagerBarcelona, Cataluña, Spain
“Good enough” is, in fact, an acceptance criterion defined for each deliverable. These criteria are established during project planning (for example, using the MoSCoW technique) and are further refined when drafting documents such as the User Requirements Specification (URS). Once the URS is approved, any changes must follow the Change Control process. Failure to adhere to this process leads to wasted time, resources, and unnecessary frustration. Saving Changes...
“Good enough” As a project manager, I use the task's objectives and established acceptance criteria to find a balance among value and perfection. When the deliverable satisfies the necessary specifications without incurring needless risk or delay, I cease refining. "Good enough" is a deliberate choice rather than a compromise when there are specific requirements and early stakeholder alignment. Saving Changes...
Community Champion
