Readiness Is Not a Milestone
When organizations commit to a major initiative, the visible milestone is often the launch date. Behind that date, dozens of commitments begin consuming resources long before the initiative delivers any value. Vendors reserve implementation teams. Employees leave other work to attend training. Legal executes contracts. Travel gets booked. Project teams reorganize their priorities, and operational leaders begin preparing their organizations for a new way of working.
Those commitments are expensive, and they are not easily reversed. Once people reserve capacity, that capacity is no longer available somewhere else. If the initiative pauses because a key dependency has not been resolved, the cost rarely shows up as a dramatic line item on a financial statement; it shows up as idle vendor resources, employees waiting for work they cannot yet perform, refresher training because too much time has passed, contract amendments, schedule revisions, and opportunities delayed while the organization catches up.
I have seen this pattern often enough to believe we sometimes ask the wrong question. We spend a great deal of time asking whether we can meet a particular launch date, and far less time asking whether the organization has created the conditions necessary for that launch to succeed.
Launching on schedule is an outcome; organizational readiness is the work that makes that outcome possible. By readiness, I don't mean executive approval or a completed project plan. I mean that the people, processes, technology, partners, and governance required to support the decision have matured to the point where they can absorb the change productively. A strategic decision does not reduce the amount of work ahead. It determines what work must now be designed.
Once leadership commits to a direction, operational leaders must translate strategy into an operating model that people can execute consistently. Customer support needs to understand how demand will arrive and how work will flow. Sales teams need clarity about what they are selling and when customers can reasonably expect delivery. Technology teams must understand the systems and integrations required to support the new capability. Finance, training, customer support, vendors, and frontline managers all have work to do before the first customer experiences the new offering.
Knowing that change is coming does not help a service organization redesign its work. People need enough operational detail to decide staffing, workflows, decision points, handoffs, measures, systems, and training. Awareness creates anticipation. Design creates readiness.
This is where I see organizations underestimate the effort involved. Executive decisions often happen over days or weeks. The work required to operationalize those decisions follows a different rhythm, because it depends on coordination across multiple functions, each with its own responsibilities, constraints, and dependencies. Compressing that work into an aggressive implementation schedule does not eliminate it — it simply postpones difficult decisions until after resources have already been committed.
Donald Sull and his colleagues reached a similar conclusion from a different direction. Their research suggests that organizations often attribute execution problems to poor alignment when the deeper challenge is coordinating work across functions. That distinction matters; most organizations understand what they are trying to accomplish, and the difficulty lies in synchronizing the work of the people responsible for making it happen. In one study, only a small percentage of managers reported they could rely on colleagues in other parts of the organization all of the time. Coordination, not commitment, proved to be the constraint.
Stanley McChrystal spent years working inside that same coordination problem, in a much higher-stakes environment. Running the Joint Special Operations Command, he found that decisions made at the top and information gathered from below could not keep pace with conditions that changed faster than that information could travel up the chain. His answer was to push decision authority down to the people closest to the work, because they held the information leadership needed and did not have time to wait for it to arrive through the usual channels. The same principle applies to readiness: the people who know whether an organization can absorb a launch are rarely the ones deciding when it happens.
Readiness deserves far more attention than it often receives. It is not another project milestone, a steering committee approval, or a green status indicator on a dashboard. Demonstrated readiness looks like a workflow that has been tested under real volume, a team that has practiced the new process rather than merely been briefed on it. Assumed readiness looks like a plan that was approved and a meeting where no one raised an objection. When readiness is assumed rather than demonstrated, organizations begin spending money before they are positioned to receive the return on that investment.
Before setting a date, it helps to ask a few questions matched to each of these areas. Have the people who will do this work practiced it, or only been briefed on it? Is the new workflow defined clearly enough that two different teams would execute it the same way? Have the systems and integrations been tested under real volume, or only confirmed against a specification document? Have vendors and partners confirmed their own readiness, or have we assumed it because the contract is signed? And if a dependency isn't ready, is there a clear decision-maker who can adjust the date — or does the date move forward regardless?
This is also where alignment, collaboration, and trust reinforce one another. Alignment ensures every function understands the objective and the role it plays in achieving it. Collaboration brings together the people who understand the work well enough to identify dependencies before they become delays. Trust allows those dependencies to be raised early, while there is still time to adjust plans, without treating legitimate concerns as resistance or pessimism.
Every meaningful initiative involves uncertainty. Markets shift, products evolve, customer demand surprises us, and competitors respond in unexpected ways. Those uncertainties cannot be eliminated, nor should they prevent organizations from moving decisively. The greater risk is committing scarce resources before the organization has established enough evidence that those resources can be used effectively.
The better planning question is not "can we launch by this date." It is "what evidence do we have that the organization is ready to commit the resources this date requires."
Bearing Check
Think about your organization's next major initiative. Before implementation teams are reserved, contracts are signed, and employees are trained, what evidence will tell you that the operational design is ready — not just the strategy? Which dependencies still need to move from assumption to confidence before you commit valuable resources?