Sandeep DamodaranProduction Engineer| Metito Overseas LimitedDubai, DU, United Arab Emirates
In my experience, the “last 5%” often slows down because it’s rarely just about execution — it’s about closure. By the final stretch, most major deliverables are done, but what remains are:
Fine-tuning and defect resolution that require precision and multiple reviews.
Dependency bottlenecks (e.g., waiting on sign-offs, vendor handovers, or final integrations).
Change creep as stakeholders request “just one more” enhancement.
Team fatigue after the intense push of earlier phases.
To maintain momentum through the finish line, I’ve found three practices make the biggest difference:
1️⃣ Define “done” clearly from day one – Ensure acceptance criteria are agreed upfront so there’s no ambiguity in the last phase.
2️⃣ Front-load closure tasks – Where possible, tackle documentation, testing, and training activities earlier, so the final weeks aren’t overloaded.
3️⃣ Keep the energy up – Recognize small wins in the final stage, rotate tasks to reduce fatigue, and keep communication tight to resolve blockers quickly.
The last 5% is often where stakeholder trust is cemented or lost. Treat it as a planned phase with the same focus as the kickoff, and it can become a smooth handover instead of a long drag.
...
1 reply by Sandeep Kashyap
Aug 18, 2025 9:23 AM
Sandeep Kashyap
...
Brilliantly put, I like how you framed the ‘last 5%’ as a closure phase in its own right. Too often, teams treat it as just polishing, but in reality, it’s where trust is cemented, like you said. I especially liked your point on front-loading closure tasks, something most teams overlook. Have you found resistance from stakeholders when you try to set those clear ‘done’ criteria upfront?
Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Barry Bohem´s Cone of Uncertainty is what you need to take a look to have the answer.
...
1 reply by Sandeep Kashyap
Aug 18, 2025 9:23 AM
Sandeep Kashyap
...
Thanks for pointing out Boehm’s Cone of Uncertainty, Sergio. That’s a sharp connection.
Often times this happens because the team & PM have focused on the "low hanging fruit" portion of scope first and the really tricky requirements which possess the greatest delivery risk have been left to the end. So the project stays green for more than half of its duration and then suddenly bogs down.
A lot might also have to do with the lifecycle and domain the project is in. For example, with a product being developed for a highly regulated industry, the final stage might be a regulator's review of the product and that might take much longer than expected.
Kiron
...
1 reply by Sandeep Kashyap
Aug 18, 2025 9:24 AM
Sandeep Kashyap
...
I couldn’t agree more, leaving the tricky requirements till the end is like keeping the hardest assignment for the last day. The project looks 'green' on dashboards, but the risk is quietly accumulating. Do you think agile/iterative approaches help here, or do they just shift the risk?
The remaining 5-10% of tasks, effort, or duration?
In the predictive software world, the remaining 5-10% can put you in the middle of testing, or more accurately, fixing unexpected bugs. It may only be 5%, or less, of the tasks remaining, but a series of cascading defects can blow up both the effort and duration required to finish. Conversations need to be held regarding how critical the unfinished features are and if you can launch without them, finishing them after launch, or if you need to postpone launch due to the critical nature of the features.
In this case, it's not about momentum, it's about the unknown unknowns - black swan defects - and possibly known unknowns if you didn't account for defects, in the schedule, even though you knew there would be some. There almost always are.
...
1 reply by Sandeep Kashyap
Aug 18, 2025 9:24 AM
Sandeep Kashyap
...
I like how you framed it, it’s less about momentum and more about the unknown unknowns. Those cascading bugs can be brutal. I’ve seen countless teams really struggle to decide whether to cut scope and launch or push deadlines to polish. How would you recommend balancing that trade-off without losing stakeholder trust?
The last 5–10% takes longer because this is when small but tricky problems show up, like final testing, approvals, and fixing small mistakes. PMI says about 1 in 5 delays happen at this stage because of last-minute changes or waiting for others to finish their part.
Also, the team may feel less energy because they’ve been working on it for a long time. To keep things moving, break the last tasks into small steps, assign clear responsibilities to finish, and celebrate small wins to keep everyone motivated.
...
1 reply by Sandeep Kashyap
Aug 18, 2025 9:24 AM
Sandeep Kashyap
...
Spot on, Syed, those 'small but tricky problems' often eat up disproportionate time. And yes, team energy is a very real factor. I’ve noticed that celebrating small wins at the end almost has more impact than in the middle because it helps everyone push through the fatigue. What’s your go-to way to keep morale high in those final stages?
In my experience, the “last 5%” often slows down because it’s rarely just about execution — it’s about closure. By the final stretch, most major deliverables are done, but what remains are:
Fine-tuning and defect resolution that require precision and multiple reviews.
Dependency bottlenecks (e.g., waiting on sign-offs, vendor handovers, or final integrations).
Change creep as stakeholders request “just one more” enhancement.
Team fatigue after the intense push of earlier phases.
To maintain momentum through the finish line, I’ve found three practices make the biggest difference:
1️⃣ Define “done” clearly from day one – Ensure acceptance criteria are agreed upfront so there’s no ambiguity in the last phase.
2️⃣ Front-load closure tasks – Where possible, tackle documentation, testing, and training activities earlier, so the final weeks aren’t overloaded.
3️⃣ Keep the energy up – Recognize small wins in the final stage, rotate tasks to reduce fatigue, and keep communication tight to resolve blockers quickly.
The last 5% is often where stakeholder trust is cemented or lost. Treat it as a planned phase with the same focus as the kickoff, and it can become a smooth handover instead of a long drag.
Brilliantly put, I like how you framed the ‘last 5%’ as a closure phase in its own right. Too often, teams treat it as just polishing, but in reality, it’s where trust is cemented, like you said. I especially liked your point on front-loading closure tasks, something most teams overlook. Have you found resistance from stakeholders when you try to set those clear ‘done’ criteria upfront? Saving Changes...
Often times this happens because the team & PM have focused on the "low hanging fruit" portion of scope first and the really tricky requirements which possess the greatest delivery risk have been left to the end. So the project stays green for more than half of its duration and then suddenly bogs down.
A lot might also have to do with the lifecycle and domain the project is in. For example, with a product being developed for a highly regulated industry, the final stage might be a regulator's review of the product and that might take much longer than expected.
Kiron
I couldn’t agree more, leaving the tricky requirements till the end is like keeping the hardest assignment for the last day. The project looks 'green' on dashboards, but the risk is quietly accumulating. Do you think agile/iterative approaches help here, or do they just shift the risk?
...
1 reply by Kiron Bondale
Aug 18, 2025 10:01 AM
Kiron Bondale
...
If the team embraces one of the tenets of adaptive approaches it would definitely use level of risk as a prioritization criterion for work items and tackle some of the riskiest items early on to reduce the cost of failure and to increase the level of confidence as time passes.
The remaining 5-10% of tasks, effort, or duration?
In the predictive software world, the remaining 5-10% can put you in the middle of testing, or more accurately, fixing unexpected bugs. It may only be 5%, or less, of the tasks remaining, but a series of cascading defects can blow up both the effort and duration required to finish. Conversations need to be held regarding how critical the unfinished features are and if you can launch without them, finishing them after launch, or if you need to postpone launch due to the critical nature of the features.
In this case, it's not about momentum, it's about the unknown unknowns - black swan defects - and possibly known unknowns if you didn't account for defects, in the schedule, even though you knew there would be some. There almost always are.
I like how you framed it, it’s less about momentum and more about the unknown unknowns. Those cascading bugs can be brutal. I’ve seen countless teams really struggle to decide whether to cut scope and launch or push deadlines to polish. How would you recommend balancing that trade-off without losing stakeholder trust?
...
1 reply by Aaron Porter
Aug 19, 2025 12:33 AM
Aaron Porter
...
How would I recommend balancing that trade-off without losing stakeholder trust?
Transparency. Open, honest communication, and no attempt to bias the decision. I only make a recommendation if they ask (for the most part). It's a conversation something along the lines of, "Here's where we're at, here's the impact if we can't go live without this, here's the impact if we wait until after launch to fix and implement this ... (allow time for questions) ... How would you like to proceed?"
I said "for the most part" because, for example, there are times when it's better to deliver something functional by a constraining deadline, such as compliance, than to miss the deadline and not be able to communicate with the compliance authority when we'll be able to launch. The sponsor is usually aware of compliance dates, but may not be familiar with the flexibility allowed, as long as minimum criteria is met and there is a plan to finish.
The last 5–10% takes longer because this is when small but tricky problems show up, like final testing, approvals, and fixing small mistakes. PMI says about 1 in 5 delays happen at this stage because of last-minute changes or waiting for others to finish their part.
Also, the team may feel less energy because they’ve been working on it for a long time. To keep things moving, break the last tasks into small steps, assign clear responsibilities to finish, and celebrate small wins to keep everyone motivated.
Spot on, Syed, those 'small but tricky problems' often eat up disproportionate time. And yes, team energy is a very real factor. I’ve noticed that celebrating small wins at the end almost has more impact than in the middle because it helps everyone push through the fatigue. What’s your go-to way to keep morale high in those final stages? Saving Changes...
Community Champion
