Nine decisions thatsettle an enterprisebuild

A project owner signs off on deliverables. An outcome owner answers for whether the thing worked. On most enterprise builds the first role is filled on day one and the second is never filled at all, which is why a system can be delivered on time, on budget, and ignored by the department it was built for.

The outcome owner has to be a single named person inside the client organisation with the authority to change how their own team works. Not a steering committee. A committee can approve a requirement, but it cannot tell forty people in a warehouse to stop using the spreadsheet they trust. If nobody can issue that instruction, you are not building a system, you are building an option.

The test is blunt. Ask who will be measured on adoption six months after launch. If the answer is a vendor, a project manager, or silence, stop and fix that before writing a line of code. Everything downstream — scope, priorities, the willingness to cut features — is decided by whether that person exists.

Requirements arrive sorted by department, because that is who was interviewed. Finance wants the ledger view, operations wants the dispatch board, compliance wants the export. Built as asked, the system becomes a federation of three small products that happen to share a login, and the seams between them are where the work actually fails.

The correcting move is to re-cut the scope along the path of the work rather than the shape of the building. One order, one claim, one patient, one shipment — follow it end to end and write down every hand-off, every status change, every moment a human waits for another human. That list is the real specification. Departments are how the organisation is funded, not how the work flows.

This re-cut is also where the first honest conversation about phasing happens. A path has a start and an end, so you can ship a complete path for one category of work and leave the other five on the old process for a quarter. A department-shaped scope cannot be phased, because half of a department's screens is nobody's working system.

Three options, and the argument is usually conducted as if only the first two exist. Buying is fast until the first requirement that the vendor's data model forbids. Building is flexible until you remember that you have also signed up to operate it for a decade. Bending — extending the platform the organisation already runs — is unglamorous and very often correct.

A workable rule: build what the organisation competes on, buy what it merely needs, and bend where the existing system is already the system of record. Payroll is a buy. The pricing engine that nobody else in the sector has is a build. The approval workflow sitting on top of an ERP that already holds every vendor record is a bend, and rebuilding it from scratch is how teams spend eighteen months recreating permissions.

Write the decision down with its reasoning, because it will be challenged — usually by a new stakeholder in month five who was not in the room. A one-page record of what was considered and why ends that conversation in ten minutes instead of a fortnight.

In consumer product work you can design the interface and let the schema follow. In enterprise work the schema is the product. The organisation already has nouns — account, site, asset, contract, case — and those nouns already have meanings that differ by department in ways nobody has written down. Two teams using the word customer for two different things is not a naming problem, it is a reporting problem that surfaces eleven months later.

So the first artefact is not a wireframe. It is a model with every entity named, every relationship cardinality stated, and — the part teams skip — the lifecycle of each entity: what states it can be in, who can move it between them, and what must be true for each move to be legal. Most enterprise bugs that matter are illegal state transitions, not broken layouts.

Argue about this on paper, with the people who own the nouns, before anything is built. It is the cheapest argument in the project. The same argument held after the fourth screen is a migration, and after go-live it is a negotiation with historical data that cannot be re-asked.

An enterprise application is rarely alone. It reads from an identity provider, writes to a finance system, pushes events to a warehouse, and is read by two reporting tools nobody mentioned in discovery. Each of those connections has an owner, a change window, a test environment that may or may not exist, and a person who answers emails at a speed you do not control.

That is why integration slips are schedule risk rather than engineering risk. The work is usually a week; the access, the credentials, the sandbox and the sign-off are usually a quarter. Start every integration with a single request: a working credential against a non-production instance, before any code. The date you receive it is the honest start date for that stream.

Two habits make the rest survivable. Put a contract between your system and theirs — an anti-corruption layer that translates their nouns into yours — so a vendor's schema change does not reach your core. And record every outbound call with enough context to replay it, because when a downstream team claims they never received an event, the argument ends at whoever has the log.

Consumer products have users. Enterprises have roles, and a person holds several of them at once, and one of them is temporary because they are covering a colleague's leave. Modelling that as a single role field on a user row is the most common structural mistake in the category, and it is unpickable later because permissions end up hard-coded into every screen that was shipped on top of it.

Decide early whether access is role-based, attribute-based, or a hybrid, and whether it is scoped by organisational unit, by geography, by record ownership, or by all three. Then make the check a single call that every feature uses. The point is not elegance. The point is that when compliance asks in month fourteen who could see a record on a date, there is one place to read the answer out of.

Audit is the same bargain. Append-only, written at the moment of the change, carrying the actor, the before value, the after value and the reason where one is required. Added at the end, it is a rewrite of every write path in the system. Added at the start, it costs a day and settles disputes for a decade.

How many environments, who owns each one, what data lives in them, and what has to be true for a change to move from one to the next. Four questions. Teams that answer them in week one release weekly for the life of the project. Teams that leave them to the client's infrastructure group discover in month six that staging shares a database with another department and can only be refreshed on request.

Insist on one environment with production-shaped data — volume, messiness and all, anonymised where the law requires it. A clean seeded dataset will pass every test and tell you nothing. The queries that fall over do so because of a table with nine million rows and an index that made sense when it had nine thousand.

Then make the release boring. One pipeline, same artefact promoted forward, migrations that run forward and can be rolled forward again, and a feature flag for anything that changes what a user sees. The purpose of all of it is to decouple deploying from releasing, so a cautious organisation can ship code continuously and turn behaviour on when it is ready to answer the phone.

The old data is never as described. There are records with no owner, dates in three formats, a status code that was retired in 2019 and still appears four thousand times, and a free-text field that an entire department has been using as a structured one. None of this is in the documentation because none of it was decided — it accumulated.

So run the migration early and repeatedly, not once at the end. The first dry run should happen as soon as the data model is stable, and every run should produce a reconciliation report: counts in, counts out, rows rejected, and why. Those rejects are the specification for the clean-up work that the client's own team has to do, and they need months of notice, not a weekend.

Cutover itself needs a written sequence with times, owners, a verification step after each one, and an explicit decision point where somebody says go or no-go against criteria agreed in advance. Also write the rollback. It is almost never used, and the hour spent writing it is what lets the team proceed calmly.

A launch is a date. A run is a commitment: who watches the dashboards, who is called at two in the morning, how a user reports something broken, how fast a fix reaches production, and who decides what gets built next now that real people are using it. Deciding this in month one changes the architecture, because a system somebody has to operate is built differently from one somebody has to demonstrate.

The practical minimum is small. Structured logs with a request identifier that survives across services. A handful of alerts tied to things users feel — checkout failing, a queue growing, a nightly job not finishing — rather than CPU graphs. One dashboard the client's own team can read without a developer. And a standing half-hour each week where somebody looks at what actually happened.

The last part is the one that compounds. An enterprise system earns its budget in year two and three, and it only gets there if someone keeps deciding what it should become. Treat the hand-over as the first week of operation rather than the last week of the project, and the system has a chance of still being the one people use when the next re-platforming conversation starts.