"What's Slipping That Worries You?"

We're in the second quarter. If something didn't get done in Q1, now is the time to ask the question no one wants to answer, and do something about it.

Key Takeaways

• Slippage rarely announces itself. It accumulates quietly, in sprint reviews that gloss over capacity gaps, in scope that no one formally challenged, and in assumptions that were never tested out loud.

  
  

• The most dangerous kind of slippage isn't the work that's late. It's the work that looks on track, because no one stopped to do the math.

  
  

• Recovery is almost always possible in Q2, but it requires one thing most teams resist: honest prioritization. Not everything can be saved. The real skill is deciding what matters most.

  
  

• Slippage often starts with a planning assumption, not a failure of execution. The team didn't fall apart. The plan was never realistic to begin with.

  
  

• Asking "why did it slip?" is more valuable than asking "how do we catch up?" One gets you tactical scrambling. The other gets you structural change.

  
  

Why This Matters

We are now in the second quarter of the year. For many teams, the projects that were supposed to be underway or already delivered, are somewhere in a spreadsheet, quietly yellow or politely described as "in progress."

Q2 is a pivotal moment. It's not so early that nothing has happened, and not so late that nothing can be done. But only if you're honest about what Q1 actually produced.

So let me ask you directly: Reflecting on the first quarter, which specific objectives were not accomplished despite your initial expectations? And more importantly, do you know why?

I've worked inside large, complex organizations for over 15 years managing multi-million-dollar programs. I've seen teams sprint hard toward deadlines that were mathematically impossible from the start. I've also seen teams recover - not by working harder, but by thinking more clearly.

The difference, almost every time, came down to who was willing to ask the uncomfortable question early enough to do something about it.

The Experience That Changed My Perspective

Some years ago, I was managing a major product launch, a new broadband offering that required a significant amount of systems development across multiple teams.

Early in the planning process, the team and I mapped out all the functionality that needed to be built for the pilot launch: ordering, activation, billing, customer care, installation workflows, the full end-to-end experience.

When we added it all up, we were looking at approximately 1,000 story points of development work.

The team executing that work had a velocity of roughly 150 story points per sprint, a realistic throughput. And we had four sprints before the planned tech trial.

That's 600 points of capacity against 1,000 points of demand. Even before a single line of code was written, we were heading toward a shortfall.

Here's what could have happened: the team could have nodded along, accepted the timeline, worked nights and weekends, and then arrived at the tech trial date 40% incomplete, with everyone surprised and no one accountable.

Instead, we stopped. I worked with the teams to assess what was truly needed for the tech trial versus what could be deferred.

We identified a large cluster of digital ordering stories, real work, important work, but not essential for the trial. Those moved to a later window, during a scheduled development moratorium. We also reallocated some promotional work, simplifying the scope enough to be achievable.

The result: we reduced the required story points by approximately 20% and brought in additional resources to increase capacity. We started the tech trial on time. The pilot also launched as planned.

None of that would have happened if we hadn't looked at the math honestly and early.

The Insight Most People Miss

Most teams treat slippage as an execution problem. The narrative goes: the team didn't move fast enough, the deadline wasn't taken seriously, someone dropped the ball.

But in my experience, that's rarely the real story.

Slippage is usually a planning problem dressed up as an execution problem.

The scope was too large for the timeline. The team's realistic capacity was never factored into the roadmap. Dependencies weren't mapped. And assumptions, about what was "required" versus "desired", were never tested against reality.

When I walk into a project that's behind, my first question isn't "who's responsible?" My first question is: What did the original plan assume, and were those assumptions ever validated?

That single shift from blame to diagnosis, changes everything. It makes honest conversation possible. It surfaces the actual decision that needs to be made. And it opens the door to real recovery rather than performative urgency.

How I Approach This Today

When a team comes to me in Q2 worried about what didn't land in Q1, I start with four questions:

1. What was the original plan, and what did it assume?

Not the optimistic version. The version with actual resources, actual timelines, and actual dependencies mapped out. Sometimes this document doesn't exist. That itself is telling.

2. What was the realistic capacity?

Team velocity. Available bandwidth. Competing priorities. Were those factored in? If not, slippage was already locked in before the quarter started.

3. What is the true priority within what's remaining?

This is the hard conversation. Not everything slipped equally. Some of what's behind matters a great deal. Some of it, if you're honest, can wait. Separating those two is where the real leverage lives.

4. Is there still time to recover? and what would that actually take?

Sometimes the answer is yes, with a clear plan. Sometimes the honest answer is: the timeline needs to move, and the sooner that's acknowledged, the better the outcome. Pretending otherwise costs more than the adjustment.

This is not a complicated framework. But it requires someone willing to ask these questions without flinching and to sit with the answers long enough to do something useful with them.

Who This Is For (and Who It's Not)

This is for program leaders, project managers, and senior operators who are responsible for delivering on commitments and who suspect that something in their portfolio is quietly behind, without a clear plan to address it.

It's for leaders who are willing to ask hard questions, have honest conversations with their teams, and make the tough prioritization calls that recovery requires.

It is not for teams looking for a way to explain away slippage without changing anything. If the goal is a better status update rather than a better outcome, this won't help.

And it is not for organizations where every deadline is immovable and every scope item is non-negotiable, because in those environments, the real problem is upstream of the project team, and no amount of execution discipline fixes a broken planning culture.

Share your experience in the comments. I'd love to learn from what you're seeing.

If this is a situation you're coming across, let's connect and talk through it or join us at our next free session around this very topic.

Smriti Sridhara is an execution-driven telecom leader with over a decade of experience at Verizon, where she has led high-impact, revenue-generating programs from strategy through national launch. She has spearheaded major pricing and value-proposition transformations, including large-scale Unlimited plan initiatives that drove hundreds of thousands of new accounts and strengthened customer growth.

Known for aligning cross-functional teams across Marketing, Network, IT, Finance, Customer Care, and Supply Chain, Smriti brings clarity and momentum to complex programs. Her expertise spans product strategy, go-to-market execution, AI-enabled delivery practices, and large-scale operational rollouts—consistently translating vision into measurable business results.