TLDR:
root cause analysis → any common cause → changes to fix the cause(s) → rebuild stakeholder’s trust → bring-in accountability → tie project success with a metric
Figure: A practical framework to go from problem → trust → delivery.”
DETAILS:
Let's look at the actionable details:
A] Retrospect: Root cause identification
Impact analysis (optional):
Usually, delay = business impact. Rarely does a project miss a deadline without consequences. Let’s move to the next steps.
Root cause + Common Patterns:
Look across the late projects — what keeps showing up? Here are some real-world examples I've seen:
Scope changed mid-way (not just more features, but different, more complex ones).
Timelines got shortened the execs for business pressure.
Periodic updates were misunderstood or inaccurately recorded.
No demos were shown stakeholders (product managers, business execs) early enough
Requirements were not properly understood for a long period at the beginning of the project.
For some projects, proper environments are necessary; for such projects, if those environments aren’t available then delay will happen
Resource crunch (unplanned leave, churn)
Conflicting priorities came (such as, another high priority project came)
B] Forward-Looking: Prevent It from Happening Again
Once you identify the causes, your real job begins — fixing the process so it doesn’t repeat.:
Better Requirements Understanding.
Run proper grooming sessions led by the product manager. Here's what works well:
PM shares PRD in advance (ideally a day before).
Engineering, design, and QA attend and ask exploratory questions.
Do a T-shirt size estimate with buffers for infra, DB migrations, frontend/backend/API changes/security, etc.
Communicate Scope/Timeline Changes.
If the scope is changed, then it’s of utmost importance to re-analyse the timeline and if changed, then broadcast it to all the stakeholders immediately.
Conflicting priorities came.
This happens too – say, another more important project came over from an executive but the PM still wants their project to be delivered on time. This is a conflict – and this happens more often than you might think.
In such cases, it’s of utmost importance for an EM to be empathetic and data-driven, both. Meet with both the executive and the PM and try to understand the importance, urgency, impact of each project. With your limited team-strength, see what you can practically deliver.
Things you can consider:
Can you partially deliver the MVP for both and then incrementally proceed for both?
Can one project follow another?
Can you take help from another EM a few engineers for a certain period.
Always remember, your responsibility, as an EM, is to help the business grow (and not to shrink it).
Bring-in or re-establish accountability:
Introduce accountability (if not present) by creating clear ownership for each deliverable — not just at the engineer level but also for leads and reviewers. Frequently get updates from the owners on potential risks and blockers, progress, etc. Let the stakeholders know that you’ve established the ownership and accountability as part of the project delivery – this will help rebuild their trust.
(Re)Building stakeholders’ trust: This is very very important. After a missed deadline, trust takes a hit. Don’t just apologize — show how you're addressing it.
Share root cause summaries with stakeholders.
Start a culture of frequent demos — stakeholders can catch gaps much earlier.
Proactively send short progress updates, even when not asked.
(Read the room — not everyone likes this, but most appreciate transparency.)
C] Use Metric and North Star:
Numbers > Opinions.
Metrics are great ways to quantify progress, delays etc. Hence use metrics as much as you can. For example:
Days spent in each phase: backend, frontend, testing, security, platform, dogfooding etc.
Parallel vs sequential tasks.
Total timeline vs number of engineers.
Feature story points — handy if scope changes mid-way.
Define a North Star Metric (NSM):
NSM metrics is the metric that defines “done” or “completion”. For instance:
"Search results on the new page must load in under 3 seconds.”
NSM is a great way to keep intra and inter team expectations on what it means for a project to be completed.
When deadlines slip, the goal isn’t to blame — it’s to learn, fix, and regain trust.
If you’re transparent, thoughtful, and process-driven, stakeholders will start seeing your team as not just predictable, but resilient.
Hope this helps – even if a little ✌️