The first ninety days of an enterprise engineering partnership

The first ninety days decide almost everything about an engineering partnership, and the sponsor usually cannot tell how they are going. The status reports are green. The demos look plausible. The team seems busy and the invoices arrive on time. Then in month seven a date slips, and the reconstruction shows that the problem was set in week three, when an environment request went into a queue and nobody escalated it, or when the security review was scheduled for later rather than started, or when the definition of the first release quietly grew from one workflow to four.

This is a checklist for the executive sponsor, written so it can be run without a technical background. It says what should be true at day thirty, sixty and ninety, what to ask, what a good answer sounds like, and which signals mean the partnership is drifting while the report says otherwise.

The one principle behind all of it

Everything below follows from a single rule: work that is difficult should be attempted early, in small form, rather than scheduled late in full form. The things that break enterprise engineering programs are not hard to build; they are hard to arrange. Access to a production data source. A network rule between two environments. An identity integration that requires a change nobody has made in three years. A security review whose queue is six weeks long. A legal decision about whether a dataset may leave a jurisdiction.

None of those are solved by engineering effort. They are solved by calendar time and by someone senior asking. A partnership that touches every one of them in the first month, with something trivial, converts them from unknown risks into scheduled tasks. A partnership that defers them because there is nothing to deploy yet is accumulating a debt that comes due in the last quarter, when there is no slack left.

So the sponsor's job in the first ninety days is not to check progress against a plan. It is to verify that the hard, slow, external things have been touched.

Day 30: access, a deployment, and a narrowed scope

By the end of the first month, five things should be true, and each of them is checkable by asking one question.

The engineers can reach the systems. Accounts exist, permissions are granted, the virtual private network or equivalent works, and someone has actually read a row of real data rather than a sample in a spreadsheet. Ask: "Has anyone on the team queried the production source directly?" A good answer names the system and the date. A bad answer describes a request that is in progress.

Something is deployed where the finished thing will live. It does not have to do anything useful. A page that says the current version and the time is enough. The purpose is to prove the whole path: source control, build, artifact, environment, network, identity, monitoring. Every one of those has a surprise in it, and the surprises are cheap in week three.

The first release is smaller than it was at kickoff. Scope should narrow in the first month as contact with real systems reveals what is difficult. A first release that has grown is a sign that nobody has met the data yet, because real data almost always makes the plan more modest.

There is a named person on your side who answers fast. Not a committee, not a steering group. One person who can approve an access request, resolve a priority conflict and decide a scope question the same week. The absence of this person is the single most common cause of a wasted first month, and it is entirely the sponsor's to fix.

The security conversation has started. Not a scheduled review. An initial conversation in which the security team has seen the proposed architecture and said what will be required. Ask your security lead directly rather than asking the partner, because the partner will honestly report having sent the request.

What the partner should have produced

A written architecture note, a few pages, naming the major components, the significant decisions, the alternatives considered and why each was rejected, and the risks that could change the plan. Not a diagram deck. The value is in the alternatives: a document that presents one design with no rejected options is a document written to be approved rather than to record a choice.

Also a milestone plan with acceptance criteria written as tests. "The pipeline processes a day of production volume within a stated number of minutes and rejects a malformed batch with an alert" is a criterion. "High performance" is not. If the plan contains adjectives, acceptance will be a negotiation later and the schedule will absorb it.

Day 60: something real, used by someone real

By the end of the second month there should be working functionality in the destination environment, and at least one person outside the project team should have used it for something they actually needed.

That last clause is the whole test. Internal demos are not evidence. A demo runs on prepared data, in a prepared order, narrated by the person who built it. A real user arrives with a case the team did not anticipate, in a state nobody accounted for, and finds the three things that a demo never surfaces. Getting one real user in front of one real workflow in month two is worth more than three more months of building, and it is the strongest predictor of whether the eventual release lands.

Also by day sixty: the integration with the most important upstream system should be working end to end, even if only for a narrow slice. Integration is where schedules are lost, because its difficulty is set by systems the partner does not control. Sixty days is enough to know whether the difficult one is difficult. Waiting until month five to find out is how a program discovers, too late, that the source system's export runs nightly and the workflow requires it hourly.

And the benefits baseline should be recorded. Before the new system changes anything, write down the current numbers: how long the process takes now, how many cases per person per day, the current error rate, the current cost per transaction. Use numbers that already exist in a report someone reads, not numbers invented for the program. Once the system is live the baseline can no longer be measured, and a program that cannot show what it changed will struggle to justify its second year regardless of the quality of its engineering.

The steering rhythm should be running by now

Weekly at the working level between the technical lead and your product owner, thirty minutes, focused on what is blocked. Monthly for the sponsor, on one page with the same measures every time. The consistency matters more than the content: a report whose shape changes each month is a report being written to describe whatever happened rather than to answer a standing question.

The measures worth standing on: milestones accepted against milestones planned, spend against plan, the state of the security review, the count of open dependencies waiting on other teams inside your organization, production incidents, and the benefits baseline. The fourth of those is the one sponsors under-use. A list of items blocked on your own organization, reviewed monthly by someone who can unblock them, converts the most common source of delay into a solvable problem.

Day 90: production, security, and a plan built on evidence

By the end of the third month, four things should be true.

Something is in production with real users. Small is fine. Narrow is fine. In production, used by people whose work it affects, is the standard. A program that has nothing in production at ninety days is not merely behind; it has never demonstrated that it can put anything into production at all, which is a different and larger problem.

The security review is materially advanced. Findings have been issued, remediation is under way, and there is a written path to whatever approval the system needs. If the destination is a federal environment, the authorization work should be visibly running: control implementation documented, evidence being collected, the assessment path agreed. If the security review has not started by day ninety, it will decide the program's date, and nothing the engineering team does afterward will change that.

The plan for the next two quarters is built from what was learned. The original plan was written before anyone had seen the data. If the revised plan is identical to the original, either it was extraordinarily well informed or nobody is updating it, and the second is far more likely.

Your own people are involved in the code. At least one of your engineers should be reviewing changes, and ideally making some. This is the earliest possible indicator of whether knowledge transfer will happen, and it costs nothing to arrange in month three while it is expensive to retrofit in month ten.

The drift signals, and what causes each one

Four patterns account for most first-quarter failures, and each has a specific cause that the sponsor can address.

Everything is green and nothing is live. The cause is almost always that the status report measures activity rather than outcome. The fix is to change the report: replace percentage-complete with a single line naming what a user can do today that they could not do last month. A report that cannot fill that line for two consecutive months is describing a stalled program in cheerful language.

The team is waiting on your organization. Access, decisions, data, a signature, a meeting with a system owner who does not report to the sponsor. This is the most common and the most fixable cause of a lost first quarter, and it is invisible unless the blocked list is reviewed by someone with authority. Ask for the list, dated, every month, and clear it personally.

Scope grew without a decision. Somebody adds a requirement in a meeting, the team accepts it to be helpful, and nobody re-prices the milestone. Three of those and the date is gone. The countermeasure is a rule stated in week one: no scope change without a written note naming the cost, approved by the single decision-maker.

Only the partner's engineers can operate anything. The slowest of the four failures and the most expensive. The countermeasure is to schedule the first handover rehearsal in the first quarter, not the last: someone on your team deploys the system while the partner watches. Do it once at day ninety and again every quarter, and knowledge transfer stops being a promise.

How we run the first ninety days

Precision Federal starts every partnership the same way, because the sequence above is what makes the rest of the program predictable.

In the first two weeks our engineers resolve environment access and deploy something trivial to the destination environment, so the whole path is proven before there is anything worth breaking. We produce a written architecture with the decisions, the alternatives and the risks, and a milestone plan with acceptance criteria written as tests and prices attached. We ask for one named person on the client side who can decide, and we send a dated list of what we are blocked on every week, so nothing sits in a queue unnoticed.

By day sixty we aim for working functionality in the destination environment with a real user on a real case, the hardest integration proven end to end, and the benefits baseline recorded from reports the client already runs. By day ninety, something is in production, the security review is advanced with findings being worked, and the next two quarters are planned from what the first ninety days taught rather than from the original memo.

Commercially, the work is fixed-price milestones with test-shaped acceptance, or a committed team at a stated monthly cost against a quarterly roadmap. The client owns everything: code, infrastructure definitions, data, models and documentation, assigned in writing at the outset, with anything we bring named in a schedule and licensed back perpetually. Our engineers work in the client's repositories, ticket system and review process, so client staff can see every change as it happens. Where the destination is a federal environment, we run the authorization work in parallel from the first month, because the control evidence, controlled unclassified information handling, government cloud configuration and accessibility work is what decides the date. The first step is one email with a one-page brief, and we return a scoped, priced statement of work.

A short list the sponsor can run alone

• Week 2: Ask what is blocked. Clear it yourself. Repeat weekly until the list is routinely empty.
• Week 4: Ask what is deployed to the real environment and who has queried real data. Accept only specifics.
• Week 6: Read one acceptance criterion out loud. If it contains an adjective, send the milestone plan back.
• Week 8: Ask which person outside the project team has used the thing, and what they said about it.
• Week 8: Ask what number will move and what its reading is today. Have it written down before anything ships.
• Week 12: Ask what is live in production, what security found, and what changed in the plan because of what was learned.
• Week 12: Have someone on your own team deploy the system while the partner watches. Then schedule the next rehearsal.

Bottom line

Judge the first ninety days by whether the hard external things were touched early, not by whether the plan was followed. Access, a real deployment, the difficult integration, the security review and a real user should all have happened before day sixty, in small form. Something should be in production by day ninety and the plan should have changed because of what was learned. Two habits carry most of the value: clear the blocked list yourself every week, and insist that acceptance criteria contain numbers rather than adjectives. A partnership that meets this standard at ninety days rarely surprises anyone at month nine, and one that does not will surprise everyone.

Frequently asked questions