Readiness: The Work Before Enterprise Delivery

Before a large project begins, my mind starts assembling questions.

Not dates. Not yet.

I want to know what must be true, which rules cannot bend, where the work will wait, how the change will reach production, what can fail, and what evidence will tell us whether it worked.

Some of these questions become diagrams. Some become checklists, spreadsheets, test scenarios, or deployment gates. Others remain open until the right person can answer them.

This is how I prepare myself for enterprise delivery. I am not trying to predict every turn. I am trying to find the places where confidence is running ahead of evidence.

That distinction mattered during an enterprise ACH integration planned for twelve weeks that eventually took nine months.

Preparation did not save the original schedule.

It helped save the launch.

Learning to See the Work That Waits

One idea from The Phoenix Project stayed with me: viewing delivery as a flow of work.

Software teams are not assembly lines, and people are not interchangeable machines. But the manufacturing analogy made waiting visible to me. On a factory floor, unfinished work piles up where everyone can see it. In software, the pile is easier to hide. It sits inside an unanswered requirement, a pending compliance review, an unavailable environment, a cross-team dependency, or a release window nobody checked.

Once I began looking for where work waited—not only where people were working—I prepared for projects differently.

The book gave me language for the pattern. Experience made the questions my own.

Requirements Are the Beginning of the Investigation

Requirements often arrive as sentences that sound complete.

Support this file. Produce this report. Process this return. Launch for this client.

Each sentence can conceal a system of rules.

For the ACH integration, I needed to understand the entire flow: file movement, transaction states, reconciliations, returns, retries, reporting, and the systems responsible at each step. A requirement could not be considered clear merely because everyone recognized the words.

I wanted to know:

• What event begins the flow?
• Which system becomes authoritative at each stage?
• Which rules come from the product, the client, the bank, or the payment rail?
• What happens when information is missing, late, duplicated, or contradictory?
• Who can resolve an ambiguity when two interpretations are both plausible?

Mapping the flow exposed questions that a feature list did not. It also changed the planning conversation. A date based on an unexamined requirement is not an estimate. It is an assumption with a calendar attached.

I learned to delay certainty until the system had been made visible.

Rules Change the Shape of the Plan

Enterprise payments work does not live inside engineering alone.

Compliance rules influence which transactions can proceed. Client infrastructure determines how files and reports move. Banking partners introduce their own operating constraints. Release freezes and fixed deployment calendars can turn a missed window into a delay that no amount of sprint velocity can recover.

The important question is not only, “Can we build this?”

It is, “Under which rules must this continue to work?”

That question changes design and delivery. It affects validation, auditability, recovery, sequencing, and who must participate in a decision. It also exposes where the team lacks control.

Our sprint boundary was not the real boundary. The client’s release train was. A task could be complete internally and still wait weeks for the next external window.

Once that became visible, the plan had to reflect it. High-risk work moved earlier. Client calendars became part of engineering planning. Missing a date was no longer treated as a small local slip when its actual consequence was a fixed delay outside our control.

Evidence Before Reassurance

Large projects generate a steady supply of comforting language.

The work is in progress. The dependency is being handled. The requirement is almost clear. The environment should be ready.

None of those statements is useless. None is evidence by itself.

I began asking what would allow us to replace reassurance with something observable. A shared system diagram showed whether teams agreed on the flow. A tracked dependency showed whether the expected handoff had occurred. A validated report proved more than a statement that reporting was covered.

We used a sprint-level spreadsheet to surface slippage and compare internal progress with client-facing expectations. The spreadsheet was not valuable because it made the project look orderly. It was valuable when it showed that the project was not orderly.

That is what evidence should do. It should be allowed to disturb the plan.

Gathering evidence also helped when the project paused and restarted or when additional product and project stakeholders joined midstream. The artifacts preserved more than status. They preserved the reasoning that produced the current state.

Documentation became a way to reduce the cost of interruption.

Deployment Is Part of the Design

Engineering plans often become vague at the exact point where the customer becomes involved.

The code is complete. Tests pass. The remaining work is described as “deployment,” as if production were a location rather than a different operating condition.

For this integration, deployment had to be designed alongside the system.

We needed to account for enterprise release windows, reporting changes, client environments, reconciliation behavior, and the legacy transaction flow that would remain active during the transition. A missed client window could create a fixed thirty-day delay. A technically successful release could still fail if support could not interpret the resulting state.

The rollout moved in phases: test, then 1%, 5%, 20%, 50%, and finally 100%. Each step created an opportunity to compare expected behavior with production evidence before expanding exposure.

The percentages were not proof of safety. They were boundaries around uncertainty.

A phased rollout only helps when someone knows what to watch, who can stop the progression, and what evidence permits the next step.

Think About Failure While the Options Are Still Cheap

Failure-mode planning can sound pessimistic early in a project. Near launch, the same questions suddenly sound responsible.

What happens if a file is duplicated? What happens if a return is contested? What if a report is missing? Who investigates first? Which partner must be contacted? Which state can be repaired, and which action must be reversed?

We documented escalation paths for duplicate files, reversals, and missing reports. We ran scenarios with engineering and support. We clarified decision paths that crossed internal teams, the client, and banking partners.

The point was not to write down every imaginable disaster. Long lists can create the appearance of rigor while hiding the few failures that would actually change the outcome.

I wanted the team to recognize consequential failure early and respond without inventing authority under pressure.

Prepared responses reduce launch-day ambiguity. They also reveal design gaps. If nobody can explain how to recover a state, the system is not ready merely because it can create that state successfully.

Observability Makes Readiness Testable

Observability is often discussed as an operational concern. I think of it as part of project readiness.

Before launch, I want to know what healthy behavior will look like, which anomaly should demand attention, and whether we can trace an outcome across the boundaries involved. If a transaction disappears between systems, can we locate it? If residual traffic continues through a legacy path, can we measure the tail? If reconciliation diverges, will we learn before a client does?

We added dashboards and validation to detect anomalies early. After launch, returns and retries continued through legacy originators for roughly sixty days. Reporting made that tail visible until the old flow tapered off.

Without that visibility, “migration complete” would have described a milestone rather than reality.

The most meaningful result was uneventful execution. That does not mean nothing unexpected happened. It means the team had enough visibility and enough prepared responses to keep the unexpected from becoming uncontrolled.

Proactive Does Not Mean Carrying Everything Yourself

There is a trap in this way of working.

An Engineering Manager who sees missing requirements, dependencies, risks, and evidence gaps can quietly become the human control plane for the project. They remember every unresolved question, chase every owner, interpret every rule, and hold the plan together through personal vigilance.

That may rescue a moment. It does not build a durable team.

My responsibility is not to keep the entire checklist in my head. It is to make the questions visible, assign ownership, and build feedback into the work so that readiness becomes shared.

A system map should allow teams to challenge the flow. A risk discussion should name who can make the decision. An observability plan should help engineers and support recognize a problem without waiting for the manager who remembers why the dashboard was created.

Proactive leadership is not private anxiety converted into project management.

It is creating the conditions for the team to see earlier and act with more clarity.

The Questions I Carry Forward

The details change, but I return to the same areas of inquiry:

1. Requirements: What outcome are we promising, and which assumptions are hiding inside it?
2. Rules: Which product, regulatory, client, or operational constraints cannot be ignored?
3. Flow: Where does work, information, or money move—and where will it wait?
4. Evidence: What do we know, what are we assuming, and what would prove the difference?
5. Failure and deployment: How can the change fail, how will it enter production, and who can stop or recover it?
6. Observability: How will we know what the system is doing after the plan meets reality?

I call this a mental checklist, but it is not a fixed template. The questions remain recognizable. The risks they reveal change with every project.

The twelve-week estimate did not survive contact with the enterprise environment. Requirements evolved. External dependencies asserted themselves. Release calendars controlled the true critical path. Additional stakeholders and technical debt changed the work.

Preparation did not give me control over those conditions.

It gave us earlier signals, clearer choices, and a safer way to change course.

That is what readiness means to me now. Not confidence that the plan will hold.

Confidence that reality will have fewer places to hide when it does not.