What we need from you to start

The list is shorter than you expect, and harder

Most companies preparing to hire an engineering firm spend their preparation time on the wrong artifact. They write a requirements document. It takes three weeks, it goes to eleven pages, it is assembled by committee, and roughly half of it describes what somebody wishes the current process were rather than what it is. Meanwhile the four things that actually gate the work — a person who can decide, a copy of the real data, credentials to the systems, and forty-five minutes watching somebody do the job — are not arranged, and the first three weeks of a paid engagement go into arranging them.

This is the list we send before a contract is signed, and it is deliberately short. Every item on it is something only you can supply. Anything we can figure out ourselves is not on the list, which is why the requirements document is not on it.

One person who decides

This is the item that determines the outcome, and it is the one most often answered with a committee. A steering group of six can approve a budget. It cannot answer whether a customer credit hold should block a quote or only block a shipment, because six people have four opinions and the meeting to resolve it is in nine days.

What the role requires: enough authority that their answer is final, and enough proximity to the work that they know the answer. Those two often sit in different people, and when they do, name the proximate one and have the senior one say publicly that this person decides. A distribution business usually finds this in an operations manager, not a vice president. A multi-site clinic group finds it in a practice administrator, not the managing physician. A specialty insurer finds it in a lead underwriter or the person who owns the rating rules, not the chief underwriting officer.

Expect this person to spend three to five hours a week during an active build. That is a real cost and it should be discussed with them before it is committed on their behalf. A decider who was volunteered by someone else, and who is already carrying a full job, will answer late, and late answers are what turn a ten-week build into sixteen.

Real data, and please do not tidy it first

The instinct to send a clean sample is universal and it is the most expensive courtesy in this business. A distributor sends two hundred well-formed order lines. The production table has four million, of which some fraction carry a customer name typed three different ways, a unit-of-measure field that means cases in one division and eaches in another, and about six thousand rows created by a 2014 migration that nobody has been willing to delete.

Those six thousand rows are the requirement. Software built against the clean two hundred works beautifully in a demonstration and fails in the second week of production, and the failure surfaces as a warehouse worker saying the new system is wrong, which it is.

What to send, in order of usefulness. A full table or a full file beats a sample. A sample of whole records beats a sample of selected columns. If volume is a problem, send everything for a narrow slice — one branch, one product line, one month including a month-end — rather than a thin skim of everything. And send the exports and reports people currently rely on, because the spreadsheet somebody maintains by hand every Monday morning tells you exactly which question the system does not answer.

Sensitive fields are a real constraint and a solvable one. Patient names, member identifiers, payroll figures and pricing that is contractually confidential can be masked, tokenized consistently, or held out entirely, and the work proceeds. The rule is to remove identity, not to remove mess. Replacing a name with a token keeps the shape of the data. Deleting every row that looks unusual destroys it.

Access, and why it takes longer than anyone plans

Access is the most common reason a start date slips, and almost none of the delay is technical. A read-only account in an on-premise system needs someone with admin rights and a free hour. A cloud application often needs a paid seat. A vendor-hosted system frequently requires a support ticket, sometimes a contract amendment, and occasionally an API fee that nobody has budgeted. Two to four weeks is normal for the third case, and it is the case most companies are in.

Start it before the contract is signed. There is no downside: an account that goes unused costs nothing, and an account that arrives three weeks late costs three weeks. Practical shapes that work, from best to worst: a read-only replica of the database, a sandbox or test instance with realistic data, a scheduled export to a shared location, and, last, a screen-share with somebody who has access. The last one works but it is slow and it consumes their day, not ours.

What we need from you is not usually admin rights. Read access plus a written description of what a change would touch is enough for the first several weeks, and it is a far easier approval to get.

Forty-five minutes watching the job get done

The documented process and the performed process are different documents, and only one of them is real. A commercial roofing contractor has a change-order workflow in a binder and a foreman who texts a photo to the project manager, who types it into the system that evening, sometimes. A clinic has a scheduling policy and a front-desk coordinator who keeps a paper list of patients who may be double-booked because they habitually run late. A manufacturer has a quality hold procedure and a line lead who calls the supervisor first because the system takes four minutes and the line is stopped.

Those workarounds are the most valuable information in the building. Each one marks a place where the current system fails, and a new system that does not account for them will be worked around in exactly the same way within a month. You cannot get at them by asking, because the people doing them do not think of them as part of the process. You get at them by watching.

So the ask is small and specific: one screen-shared session with the person who actually performs the task, doing real work, with permission to interrupt and ask why. Not a manager describing it. Not a training video. If there are three roles involved, that is three sessions, and it is still the cheapest hour in the project.

A definition of done, in one paragraph

Not a specification. A statement of what will be different, for whom, and how you will know. Two examples of the shape.

Weak: "Build a dashboard for inventory." Nothing here is checkable, and three people will read it three ways.

Workable: "The purchasing lead opens one screen each morning and sees every SKU projected to stock out within fourteen days, ranked by how much revenue it moved last quarter. Today she builds this by hand from two exports and it takes about ninety minutes. Done means she stops doing that and the list matches what she would have produced, for four weeks running."

The second version tells you what to build, tells you how to test it, tells you what it is worth, and gives a plain criterion for acceptance that cannot be argued into ambiguity later. Writing it takes an afternoon and it is the single most useful page in the engagement.

What you do not need

A requirements document. If you have one, send it and we will read it. If writing one is delaying the start by three weeks, skip it. The process walkthrough plus the data extract will produce a better one in a fraction of the time.

Clean data. Covered above, and worth repeating because people delay for months over this.

A technology decision. You do not need to have chosen a database, a cloud provider, or a framework. If you have constraints — an existing platform your team can support, a vendor relationship already in place — those are useful and should be stated. A preference formed from a conference talk is not a constraint and should be held loosely.

Internal consensus. Unanimity is not a prerequisite. A named decider is. Those are different things and waiting for the first one is how a project spends a quarter not starting.

A finished business case. A rough figure for what the current pain costs — ninety minutes a day, four people, or one lost order a week — is enough to size the work sensibly. The precise return can be calculated later and is usually more honest that way.

The two weeks before day one

That last step deserves its own paragraph, because it is the one people forget and it changes plans. The constraints already known inside your business almost never appear in a kickoff. A distributor's system freeze from mid-December through the first week of January. A clinic group's payer contract renewal that consumes the administrator every February. A manufacturer's planned upgrade of the very system we are integrating with, scheduled for the second quarter by a team in a different building. An audit window. A union agreement that governs how schedules can be published. None of these are obstacles if they are known in week one. All of them are expensive in week nine.

When the honest answer is not yet

Some situations should not start, and saying so early is cheaper for everyone.

If nobody can be named as the decider after two attempts, the organization has not agreed on what it wants, and a build will surface that disagreement at the most expensive possible moment. Resolve it first. If the system you want to integrate with is being replaced within a year, build against the replacement or wait. If the process changes every quarter because the business is still figuring it out, automating it now freezes a shape you will regret; a spreadsheet is genuinely the correct tool until the shape settles.

And the case that comes up more than you would think: the problem is a policy problem wearing a software costume. Three people entering the same order because no one agreed who owns it does not need a workflow tool. It needs a decision about who owns it, which is free.

The mistakes that cost the most time

• A curated sample instead of real data, producing software that is correct against fiction
• Access requests opened after the contract is signed, spending week one on a vendor ticket
• A steering committee in place of a decider, so every question waits for a meeting
• A manager describing the process instead of the person who performs it
• A three-week requirements document written before anyone looked at the data
• Known constraints left unmentioned — the freeze, the upgrade, the audit, the seasonal peak
• A definition of done that cannot be checked, leaving acceptance to opinion
• The decider volunteered by someone else and never asked whether they have the hours

Before you kick off

• The decider is named, and has personally agreed to the time
• Access requests are open, including the slowest vendor one
• A real data extract exists, unsanitized except for identity fields
• Walkthroughs are booked with the people who do the work
• The definition of done fits in a paragraph and names a check
• Freezes, audits, peaks and planned upgrades are written down
• Somebody has said out loud what happens if this is not built

Bottom line

The preparation that helps is not documentation. It is a person, a data extract, a set of credentials, an hour of watching, and a paragraph. Everything on that list is something only your company can provide, which is exactly why it is the list. If you can arrange four of the five before a contract is signed, the first month produces working software instead of scheduling. If you cannot name the decider, fix that before you hire anyone, because no engineering firm can supply it for you.

Frequently asked questions