Skip to main content
Version: 2.0

On Time Delivery Rate

As engineering leaders, we’re bombarded with metrics. Velocity, cycle time, bug counts – the list goes on. But one metric consistently rises to the top as a crucial indicator of team health and customer satisfaction: On-Time Delivery Rate (OTDR). It seems simple – the percentage of work delivered when promised. But digging deeper, I’ve learned that focusing solely on the number can be misleading, even detrimental. This post will explore how to truly understand OTDR, identify its root causes, and build strategies for genuine improvement.

Why OTDR Matters (and Why a High Number Isn’t Always Enough)​

A healthy OTDR demonstrates predictability, reliability, and respect for commitments. It directly impacts customer trust, allows for more accurate planning, and builds a reputation for consistent performance. A consistent inability to deliver on time erodes confidence, leads to frantic fire drills, and ultimately affects the bottom line.

However, a perfect or excessively high OTDR can be a red flag. I’ve seen teams inflate estimates to ensure 100% delivery, essentially gaming the system. This creates a false sense of security and masks underlying issues like poor estimation skills, lack of prioritization, or an unwillingness to address technical debt. Consider whether you're celebrating delivery, or celebrating sandbagging?

Deconstructing the Number: Understanding the "Why" Behind the Percentage​

Before you start chasing a higher percentage, you need to understand why your current OTDR is what it is. Here's a framework I’ve used to break down the contributing factors:

  • Estimation Accuracy: This is the cornerstone. Are initial estimates realistic? Are we consistently underestimating effort due to optimism, lack of understanding of the problem, or simply not accounting for all the necessary tasks?
  • Scope Creep: Uncontrolled changes to requirements during a sprint or project are a major culprit. Are we clearly defining the "definition of done" upfront? Do we have a process for managing change requests?
  • Dependencies: External dependencies (other teams, third-party services, data feeds) can easily derail timelines. Are these dependencies identified and factored into estimates? Do you have contingency plans?
  • Technical Debt: Accumulating technical debt slows down development and increases the likelihood of unexpected issues. Is there dedicated time for refactoring and addressing technical debt?
  • Unexpected Issues/Blockers: Even with the best planning, unexpected issues arise. Is your team resilient enough to handle them effectively? Do you have a clear process for identifying and resolving blockers?
  • Capacity & Resource Constraints: Are your team members overloaded? Do they have the necessary skills and tools to complete the work?

Actionable Strategies for Improvement​

Once you’ve identified the root causes, you can start implementing strategies to improve your OTDR. Here are a few that have worked for me:

  • Invest in Estimation Techniques: When estimation consistently misses the mark, invest in techniques like story pointing, planning poker, and historical data to improve accuracy. Regularly review past estimates to identify areas for improvement.
  • Prioritize Ruthlessly: Focus on delivering the most valuable features first. Don’t try to do too much at once. Use frameworks like MoSCoW (Must have, Should have, Could have, Won't have) to prioritize effectively.
  • Manage Scope Creep with a Change Control Process: Implement a clear process for managing change requests. Require a formal review and approval process for any changes to the agreed-upon scope.
  • Address Technical Debt Proactively: Allocate dedicated time for refactoring and addressing technical debt. Make it a regular part of your sprint planning.
  • Improve Dependency Management: Identify and proactively manage external dependencies. Services like Queuemail.dev and uptime monitoring through tools like UptimeObserver can introduce external dependencies. Establish clear communication channels with dependent teams and consider building in buffer time to account for potential delays.
  • Foster a Culture of Transparency and Communication: Encourage team members to openly communicate blockers and risks. Create a safe space for experimentation and learning from failures.
  • Regular Retrospectives: Conduct regular retrospectives to identify lessons learned and implement improvements.

It’s also important to remember that sometimes, delaying delivery to ensure quality is the right decision. A relentless focus on on-time delivery shouldn't come at the expense of code quality or team morale.

Beyond the Percentage: A Holistic View​

Ultimately, OTDR is just one metric among many. It's important to consider it in the context of other factors like code quality, customer satisfaction, and team morale. A relentless focus on delivering on time at the expense of these other factors can be counterproductive.

Instead of solely focusing on the number, strive to create a healthy engineering culture that values predictability, transparency, and continuous improvement. When you do that, a positive OTDR will naturally follow.

This week, take 30 minutes with your team to map out the root causes of recent delivery delays. Start with a simple fishbone diagram and identify one actionable improvement you can implement immediately.