The first fortnight is a measurement, not a warm-up
Buyers tend to treat the opening weeks of an engagement as onboarding — a period where the vendor gets oriented and nothing much is expected. That is a costly framing, because it is the only window in the project where changing direction is nearly free. Two weeks is enough to open your real data, run something end to end, and discover the one or two facts that would otherwise be found in month three. What you should get back is not a status update. It is a small pile of concrete artifacts, each of which can be checked.
This is written from the delivery side, so treat it as a description of the standard we hold ourselves to rather than a neutral survey. It is also a standard you can apply to anyone, including us. Every item below is either present or absent; none of them requires you to be technical to assess.
You are probably here because
- Two weeks in, you have had three meetings and hold nothing you can read
- The update says “environment setup and discovery” and you cannot tell if that is normal
- A previous engagement looked fine at week two and was in trouble at week ten
- You are about to sign, and want to know what to write into the first milestone
The list below is what a first milestone can reasonably require, and each item is checkable by someone non-technical.
Six things that should exist at day fourteen
Access, confirmed by use. Not a ticket number — a screenshot or a log line showing an engineer reading from the real system. Access is the most common silent blocker, and “requested” is a different state from “working.” If it is still outstanding, the artifact is a written list of exactly what is missing, who owns each request, and the date it was submitted.
A running environment somebody else could stand up. The project should be reproducible from a clean machine by following written steps, and somebody other than its author should have tried. This sounds like housekeeping. It is the single best early predictor of whether handover will go badly, because a project that only runs on one laptop in week two will only run on one laptop in month six.
A written read of the system as it is. Two to four pages describing what actually exists, based on reading the code and the data rather than the architecture diagram you were given. Expect it to contradict the diagram in at least one place. That contradiction is worth more than the rest of the document.
A data profile with counts. Row counts by table and by month, null rates on the fields the project depends on, duplicate rates, date ranges, cardinality of the key columns, and a list of fields that turned out to be free text where structure was assumed. This is the artifact that most often changes the schedule, and it cannot be produced by anyone who has not been given real data.
A risk register with owners and dates. Five to ten items, each naming what would settle it and who can settle it. A risk without an owner and a date is a note, and notes do not get closed.
One thin slice working end to end. Not the product. The narrowest possible path from real input to real output — one document, one record, one request — running in an environment you can look at. It proves the pipes connect, which is the thing most likely to be untrue and most expensive to discover late.
The one artifact that matters most: a number you did not have before
If you take a single test from this article, take this one. By the end of two weeks the vendor should be able to tell you something quantitative about your own situation that you did not know at the start, and show you how it was derived.
It might be that the table everyone relies on has been missing a third of its rows since a migration two years ago. It might be that the process takes eleven minutes on average and forty on the exceptions, which are eighteen percent of volume. It might be that the two systems disagree about customer identity for a measurable share of records. The specifics vary. The property that matters is that it is measured rather than described, and reproducible rather than remembered.
A team that has spent two weeks in your environment and produced only adjectives has been reading documents and attending meetings. A team that arrives with a number, a query, and an explanation of what it implies has been doing the work. This test is hard to fake and takes about five minutes to apply.
Signal value of each day-14 artifact — our ranking
How much each artifact tells us about how the rest of the engagement will go. Judgment from our own work, not a study.
What good and weak versions of each look like
Most of these artifacts can be produced in a form that looks complete and says nothing. The distinction is almost always the same one: does it contain specifics that could be wrong, or only statements that cannot be?
| Artifact | Good looks like | Weak looks like |
|---|---|---|
| Data profile | Counts, null rates, date ranges, three surprises named | “Data quality is generally good, some gaps exist” |
| System read | Names the modules, contradicts the diagram in one place | A restatement of the architecture slide you supplied |
| Thin slice | Real input to real output, you can run it yourself | A recorded demo of a mock-up with sample data |
| Risk register | Owner, date, and the check that would close each item | “Data availability” and “stakeholder alignment” with no owner |
| Scope revision | Two things added, two removed, reasons given | No change, because nothing was learned |
| Environment | A second person followed the steps and it worked | “It runs locally”, on one machine, undocumented |
The scope revision nobody enjoys writing
If two weeks of real contact with your systems produced no change to the plan, the most likely explanation is that nobody looked hard. Software estimates are made from the outside; the first fortnight is when the outside view meets the inside one, and they are rarely identical.
A good revision is small and specific. Something moved earlier because it turned out to be a dependency. Something moved later or out because the data does not support it yet. Something was added because a step everyone assumed was automated is a person copying values between two systems on Fridays. The revision should be one page and should state the effect on the date and the cost plainly, including when the effect is zero.
Here is the part worth saying from the vendor side. Two weeks in is also when a vendor discovers that the job is bigger than they bid, and there is a real temptation to keep quiet, absorb it, and hope. That decision looks generous and usually ends in a hurried conversation two months later with less trust and fewer options. What you want is for the news to arrive at day fourteen, in writing, with choices attached. How a vendor handles that moment tells you more about the rest of the engagement than any part of their proposal did.
What two weeks cannot tell you
Being clear about the limits protects you from over-reading an early result in either direction.
It cannot tell you the final accuracy. An early number on a small sample moves substantially once the exceptions are in scope. Treat a day-fourteen quality figure as a sign of life, not a forecast, and be wary of a vendor who quotes one confidently.
It cannot settle the architecture. The right long-run design depends on things that are not known yet: real volumes, real latency, what the security review will permit. Early lock-in on infrastructure is a cost with no benefit at this stage.
It cannot prove the thing will be adopted. Adoption is decided by people doing their jobs on an ordinary Tuesday, and that evidence comes much later. What two weeks can do is confirm you are building for a job somebody actually does.
How to grade it in thirty minutes
You do not need to be technical, and you do not need to read the code. Four questions do most of the work.
Can someone else run it? Ask for the setup steps and have a second engineer — theirs or yours — follow them on a clean machine while you watch. This one question predicts more downstream pain than any other.
Where did the numbers come from? Ask them to re-run the query that produced a figure in the data profile, live. If the number cannot be reproduced on request, it is a recollection.
What surprised you? A team two weeks into an unfamiliar environment that reports no surprises has either not looked or is not telling you. Ask for three, and ask what each one implies for the plan.
What would you need to be wrong about for the date to move? A good answer names one or two specific assumptions and the checks that would confirm them. A vague answer means the schedule is a hope with a Gantt chart attached.
A first fortnight that earns its place
Day 0 to day 14
Two conditions make this schedule achievable, and both are on your side of the table. Access has to start at signature rather than at kickoff, and somebody who knows the domain has to be available in the first week. Where those two are missing, no vendor can produce the artifacts above, and the honest version of the day-fourteen review says so and names the dates that were missed.
If you are at day fourteen with none of this
It does not mean the vendor is bad. The most common cause is that access never arrived, which is usually an internal problem wearing a vendor-shaped coat. Establish which it is before acting, because the two have opposite remedies.
Ask for a one-page written statement of what is blocked, who owns each blocker, and what has been done in the meantime. Then give it one more week with a specific, small target: one query against real data, or one record processed end to end. A team that cannot deliver that in a week with access in hand is a team you will be having this conversation with again at month three, and it is far cheaper to have it now.
The mistakes we are called in to fix
- Two weeks spent on documents, with the real data never opened
- An environment that runs on one laptop, undocumented, and stays that way
- A plan unchanged after discovery, because discovery was a formality
- Early accuracy numbers quoted as forecasts, from a sample without the exceptions
- Access requested at kickoff instead of at signature, losing the first two weeks
- Bad news absorbed quietly by the vendor, surfacing at month three with no options left
- A risk register of abstractions with no owner, no date and no closing check
What to require in the first milestone
- Access working, evidenced by use, or a written list of what is blocked and who owns it
- Setup steps a second person has followed successfully on a clean machine
- A written read of the system as it is, naming at least one contradiction
- A data profile with counts, null rates, ranges and three named surprises
- One thin slice running end to end on real input, runnable on request
- A risk register where every item has an owner, a date and a closing check
- A one-page scope revision stating the effect on date and cost
- One measured fact about your business you did not have two weeks ago
Bottom line
The first two weeks are the cheapest information you will ever buy on a project, and most buyers spend them waiting politely. Require artifacts instead of updates: a running environment somebody else can stand up, a profile of your real data with counts in it, one thin slice working end to end, and a scope revision that says what changed. Then grade them with four questions in half an hour. Everything you learn there is available at a tenth of what the same lesson costs in month three.
Frequently asked questions
Working product, no. One narrow path from real input to real output, yes, in most engagements. The purpose is not the feature; it is proof that the connections exist and the data is what everyone believes it is. Where access is genuinely slow, the honest substitute is a written statement of what is blocked and by whom.
It depends on what they can show instead. A team without access can still produce a system read, a written question list and a plan. A team with access, two weeks in, holding nothing you can inspect is a different situation. Ask what they would need in order to show one thing next week, and see whether the answer is specific.
That is the system working. It is the cheapest moment in the project to change scope, phase the work, or stop. Findings that reduce a plan at day fourteen have saved the money they appear to be costing. What should worry you is discovery that produces no change at all.
Often it is worth it, particularly when the scope is uncertain. A short, fixed-price discovery with defined artifacts gives both sides a clean exit and gives you a written basis for the larger decision. The important part is not the contract shape; it is that the artifacts are named and dated rather than described as “discovery.”
The sponsor, the person who owns the data, and one practitioner who does the job today. That last one catches the thing the other two cannot: a finding that is technically right and does not describe the actual work. It takes them under an hour and it is the highest-value hour in the review.