A practical way to understand commitments, forecasting, capacity, communication, and software delivery performance
10 min read
Software delivery lives in a world of probabilities and predictions, not certainty. We accept this easily in other parts of life. Before a football game, we can estimate the likelihood of an outcome, but we cannot know the final score. A weather forecast several days out is useful, but it becomes better informed as the day approaches and new evidence arrives. In both cases, the prediction changes because the underlying conditions are still unfolding.
Software has the same characteristic. Requirements, technical constraints, dependencies, data, integrations, customer feedback, and other conditions reveal themselves as the work progresses. The Cynefin framework’s complex domain is a useful lens for this: cause and effect cannot always be known in advance, and understanding emerges through action, feedback, and learning. Yet decades later, many organizations still try to manage software as though it were deterministic, demanding fixed dates and precision before enough evidence exists to support them.
A trustworthy software delivery system does not eliminate uncertainty; it makes commitments, forecasts, changes, and tradeoffs visible early enough for the business to act.
This article grew from recent advisory and fractional work with organizations struggling with delivery confidence, along with many years spent scaling software organizations and improving how teams plan, build, communicate, and deliver.
The circumstances vary, but the pattern is familiar. A software team repeatedly misses expected delivery dates. Business leaders lose confidence because customers, revenue plans, budgets, contracts, and market opportunities depend on work arriving when expected. Eventually the conversation turns toward what needs to change: more people, different skills, tighter oversight, better estimation, fewer priorities, or something else.
Any of those could be part of the answer. A missed date, though, only tells us we missed an expectation. The cause could be insufficient capacity, a missing capability, changing priorities, too much work in progress, technical complexity, customer interruptions, hidden dependencies, weak execution, or risk that became visible inside the team long before leadership knew about it. From outside Engineering, many of those conditions look the same.
A missed date is an observation, not a diagnosis.
That is why I start with delivery confidence.
What Delivery Confidence Means
I think of delivery confidence as the organization’s ability to make clear, evidence-based commitments and keep everyone aligned as the work progresses and conditions change.
A commitment is much larger than a date. It includes what is being delivered, why it matters, what success looks like, expected scope and quality, timing, assumptions, dependencies, ownership, available capacity, and the uncertainty that remains.
That clarity has to survive contact with delivery.
As work progresses, assumptions are tested, constraints appear, dependencies change, and real data exposes edge cases nobody saw during planning. Those discoveries should change the forecast when necessary.
I have found it useful to separate three related forms of confidence. Delivery confidence is whether we have enough evidence and shared clarity to believe we can fulfill the commitment as it stands. Forecast confidence is how reliable our current expectation is for when and how it will be fulfilled. Stakeholder confidence is whether the people depending on the work trust that they understand its current state and will hear about meaningful changes soon enough to act.
Communication connects all three.
Software Creates Knowledge While We Build It
Some software work is familiar and reasonably predictable. Other work involves new products, complex data, unfamiliar integrations, legacy systems, new technology, or customer needs still being understood.
In those situations, important information emerges through the work itself. Implementation exposes incomplete requirements, integration reveals unexpected behavior, real data uncovers edge cases, performance testing surfaces constraints, and customer feedback changes the solution.
Implementation continues discovery. We are still accountable for planning and delivery, but a useful delivery system has to learn as it moves. Smaller integrated increments, technical experiments, quality results, and actual throughput give us better evidence about what remains and how likely the current forecast is to hold.
Even if a forecast changes as time passes, leaders still have useful choices. They can narrow scope, change sequence, remove another priority, resolve a dependency, add specialist help, accept a later date, or consciously accept more risk. When the same information arrives a few days before the expected delivery date, most of those choices have disappeared.
Useful learning matters because it preserves options.
Be Clear About What a Date Means
A surprising amount of delivery friction starts because several different concepts have been collapsed into one date.
A target is what the business wants. An estimate is an assessment of effort, complexity, or duration based on what is currently known. A forecast is the current evidence-based expectation of what is likely to happen. A commitment is a shared agreement around an outcome, its scope, quality, timing, assumptions, and remaining risk. An external constraint is a date that genuinely cannot move because of a contract, regulation, event, or another outside condition.
These distinctions matter because an early estimate can quietly become a remembered commitment. A desired business date can later sound as though Engineering supplied it. A quarter placed on a roadmap can gradually become an expected delivery date even when nobody explicitly made that commitment.
The business still needs planning information, so teams should make the best forecast the current evidence supports and keep it current as conditions change.
I explored this in Profitable Engineering through probabilistic estimation, confidence levels, and dynamic reprioritization. Early in the work, a range with an explicit level of confidence is often more useful than a precise date. As integrated work, testing, actual throughput, and resolved dependencies provide better evidence, the range should narrow, or the confidence should change, and priorities may need to change with it.
Over time, we can compare those forecasts with what actually happened. If work described as 80 percent likely succeeds only half the time, our confidence language needs recalibration. The point is practical: the organization should know whether its forecasts mean what everyone thinks they mean.
Visibility and Communication Are Part of Delivery
Progress reporting can generate a lot of activity without giving leadership much useful information.
“We are 70 percent complete” tells me very little. I still don’t know what has been proven, what remains uncertain, which dependencies are unresolved, or what could still change the outcome.
I would rather hear:
“We still expect the core workflow by June 30. Confidence has moved from high to medium because the data migration is larger than expected. By May 15 we should know whether we need to reduce the reporting scope, add specialist help, or move the date.”
Now I know the current forecast, what changed, the available choices, and when better information should become available.
One of the first questions I ask when reviewing a missed commitment is: When did the team know, and when did leadership know?
When those dates are close together, the change may reflect genuine discovery. A gap of several weeks points to communication as part of the delivery problem.
The environment leaders create matters here. If people are punished for surfacing risk early, they learn to soften or delay the message. Forecast integrity depends on being able to say, with evidence, that confidence has changed while the organization still has time to respond.
A changed forecast communicated early is a decision opportunity. The same change communicated late is a surprise.
From the executive seat, genuine discovery and late communication may look the same at first because the date moved. They should lead to very different conversations.
Understand Effective Capacity
When confidence drops, it is easy to blur several different problems together. We may be dealing with capacity or skill gaps, unstable priorities, weak forecasting, execution problems, or risks that don’t reach leadership soon enough. Those are related, but they are not the same problem.
Effective capacity is what remains after all of the work the team is responsible for has taken its share. Support, incidents, customer questions, compliance, defects, meetings, technical maintenance, existing commitments, and operational responsibilities all consume the same finite capacity used for product delivery.
In one small organization I worked with, they lacked the budget or scale for all the specialized roles you would normally see in a larger company. On paper, seven engineers looked like seven people available for product delivery. In practice, the same group was also covering releases, production issues, security, infrastructure, data quality, architecture, customer integrations, support, planning, and technical questions from Sales.
The work still exists without dedicated roles. Small organizations reasonably ask people to cover several areas; the problem is when that work consumes capacity without showing up in the plan.
RFP support, onboarding, customer escalations, compliance work, production issues, and emerging sales opportunities may never appear on the roadmap, but they still compete with it. Planning against every available hour also makes the system brittle. Some room for normal variation is part of responsible capacity planning.
New Work Has a Cost
Fast-moving companies should change priorities. Markets move, customers ask for things, revenue opportunities appear, and technical risks surface. New work can become more important than work already underway.
What matters is making the consequence visible.
New work does not enter for free. It displaces something.
When meaningful new work enters, somebody should be able to say what it displaces. Without that decision, reprioritization becomes accumulation. Work in progress grows, attention fragments, and existing commitments slow while their forecasts remain unchanged.
The context-switching cost is especially high in small teams where the same people may be covering architecture, support, planning, customer questions, and implementation.
Eventually another date slips, and estimation becomes the visible problem even though the delivery environment changed underneath it.
A better system makes the tradeoff explicit: this is now more important, this work will pause, that forecast will move, these people will shift, and this is the expected impact.
That is how a company changes direction without pretending capacity is unlimited.
What I Would Examine When Confidence Breaks Down
When I hear that a team repeatedly misses expected dates, I want to reconstruct several real commitments before recommending a change.
I want to know what kind of date was communicated, who set it, what scope everyone believed was included, what was known at the time, what changed afterward, and when the team and leadership recognized that the forecast was changing.
Then I look at the environment around the work: new demand, dependencies, quality problems, rework, customer requests, responsibilities, work in progress, and decision delays. I also want to understand where critical knowledge depends on one person and which demands consume capacity without showing up in the plan.
Patterns usually begin to emerge once the delivery system is visible.
The evidence may point to a missing capability or insufficient capacity. It may also point to too many priorities, excessive work in progress, unclear ownership, slow decisions, weak forecasting, or execution problems. In a resource-constrained organization, that distinction matters even more because every investment has an opportunity cost.
Discovery aims to identify the constraint limiting the system before deciding what to change.
Improving Delivery Confidence
The practical work does not have to become a large process.
Delivery confidence is shared across the organization. Engineering contributes evidence about feasibility, progress, quality, and risk. Product helps shape scope and priorities. Business leaders control demand and make the tradeoffs required when the evidence changes.
A small amount of standard work can keep those responsibilities connected. Start with a few real commitments and agree on how priorities are set, commitments are formed, forecasts are updated, and material changes are communicated. Make the owner, scope, dependencies, current forecast, confidence, and competing demands visible without adding unnecessary ceremony.
Review those commitments often enough that important evidence doesn’t go unnoticed for weeks. Update the forecast range and confidence as the evidence changes, and dynamically reprioritize when new work, dependencies, or risks materially affect the plan. Make clear what changed, what was displaced, which decisions are needed, and when better information will be available.
Use Metrics to Improve the Forecast
Better delivery metrics should help us understand the range of possible outcomes, what is changing that range, and whether confidence should be increasing or falling. Historical throughput, cycle-time distributions, work in progress, aging work, and actual forecast performance can provide better evidence than percent complete or a straight-line projection.
Using real delivery evidence helps us make better-informed forecasts, track how confidence changes, and recognize when the assumptions behind the forecast no longer hold.
Techniques such as Monte Carlo can use that history to express likely outcomes as ranges and probabilities. Forecast quality still depends on the underlying flow data, scope stability, WIP, and dependencies. As work progresses and uncertainty decreases, confidence should generally improve unless new evidence materially changes the picture.
Over time, compare forecasts with actual outcomes. Look for where estimates tend to fail, which dependencies repeatedly create delays, how much unplanned demand occurs, and how quickly risk reaches the people depending on the outcome. That history improves future commitments because the organization is learning from its own delivery system rather than relying only on intuition.
This fits naturally with how I think about Flow and Realization. Flow helps us understand how effectively work moves through the system. Delivery confidence tells us whether we can make and maintain credible commitments around that work. Realization asks whether what we delivered produced the customer or business outcome that justified the investment.
Diagnose Before You Prescribe
Repeated missed expectations deserve attention, as does repeated late communication.
Before changing the team, adding process, outsourcing work, or making another significant investment, understand what the delivery evidence says is actually constraining the system.
Better delivery confidence gives leaders clearer commitments, more credible forecasts, fewer surprises, and more time to act when reality changes.
That is a delivery system a business can plan around.
This also connects to the broader Flow + Realization ideas I have been applying around demand, capacity, flow, decisions, and realized business value.
Key Takeaways
- Software delivery is a forecasting process shaped by uncertainty, but many organizations still treat estimates and forecasts as fixed promises. Accepting that forecasts should improve as evidence accumulates leads to better alignment around dates, confidence, and tradeoffs.
- A missed date begins the diagnosis; it does not explain the cause.
- Delivery confidence comes from clear commitments, current evidence, and forecasts that change as we learn.
- Effective capacity includes all the work competing for the people expected to deliver the roadmap.
- New priorities have consequences; make displaced work and changed forecasts visible.
- Surface changing confidence early enough to preserve choices, then use the evidence to decide what actually needs to change.
AI helped draft and edit this article. The ideas, experiences, and perspectives are mine, drawn from industry resources, collaboration, and more than 25 years in software and technology leadership.
Further reading: Dave Snowden and Mary Boone on the Cynefin framework, Harvard Business Review (2007); Phil Clark, Profitable Engineering, profitableengineering.com.