Five questions for the first meeting with a client

Most of what a project will cost is decided in the first meeting, before anyone writes an estimate. Not by what gets agreed, but by what gets left unasked and turns into an assumption that surfaces three months later, usually on a Friday. I have narrowed my list to five questions. They are boring, they take about forty minutes, and they have saved me more time than any tool I have adopted.

What the first meeting is for

The first meeting is where you find out whether you and the person across the table are describing the same system. They have been living with the problem for a year and know things they no longer notice. You know what usually goes wrong in projects like this and have no idea which of those apply here. The meeting converts their knowledge into your constraints.

That means listening for what is implied rather than stated. A sentence like "the reports go out on Mondays" carries a scheduled job, a recipient list, a format somebody depends on, and a person who will call if it stops. The five questions exist to pull those implications into the open while it is still cheap.

1. What does success look like, in numbers

Ask for the number, the current value and how it will be read. "Faster" becomes "the export finishes in under a minute, measured on the largest account we have". "More sales" becomes "we get twenty more completed orders a week, counted in the same dashboard we look at now".

Then ask the question people skip: what result would make you call this a failure. The lower bound is more honest than the target, and it is the number you will actually be judged on.

If nobody knows the current value, say so in the meeting. Measuring it becomes the first deliverable, and that is a real piece of work rather than an oversight to absorb later. This is the same habit as taking a measurement before optimising anything: you cannot show an improvement without a starting point you agreed on.

2. What is already running that must keep running

New work lands on top of a system that already has obligations. Ask for the list, out loud, in the meeting:

• Scheduled jobs: what runs nightly, weekly, monthly, and who notices when it does not.
• Integrations: what sends data in, what pulls data out, and which partner would call first.
• Reports and exports: who receives them, in what format, and whether anyone downstream parses them.
• Manual routines: the spreadsheet somebody fills in every morning is part of the system even though it is in nobody's diagram.
• Backups and restores: when a copy was last restored rather than taken, which is a different question and usually gets a different answer, as I wrote in the post about zero byte backups.

Anything on that list that you might touch is either a constraint or a migration. Both are work. The ones that hurt are the items nobody mentions because they have never broken.

3. Who owns the data and the accounts

Ask who can grant access, not who has access. The two are different people more often than you would expect, and the first is the one that determines your schedule.

Go through it item by item: the domain registrar, the DNS, the server or cloud account, the database, the payment account, the analytics, the app store listings, the mailbox that receives system notifications. For each one, who is the owner of record, who can add a user today, and how long does that usually take.

The answer "we will find out" is a legitimate answer and a scheduling fact. A missing account owner is a queue you join rather than a task you finish, and it is the most common reason a project that was going to start on Monday starts two weeks later. Ask for the access requests to be raised the same week, before the contract is signed if possible, because they cost nothing to start and they run in parallel with everything else.

Ask for your own user on each system rather than somebody's username and password. A shared login creates three problems at once: the audit log cannot tell who did what, the work stops when that person goes on leave, and there is no clean way to close the access when the engagement ends. Say in the same meeting which accesses should be revoked at the end. It reassures people, and nobody remembers to ask for it later.

The other half of this question is legal rather than technical: whose data is it, where may it live, and what has been promised to the people in it. Hearing that in the first meeting is far cheaper than hearing it during a review.

4. What has been tried before, and why did it stop

Almost every project has a predecessor. Ask about it directly and ask what happened to it, because the reason it stopped tells you which wall you are heading for. Budget ran out. The person who cared about it moved on. A rule from outside the company made the approach impossible. A vendor stopped answering.

Very few of those reasons are technical, and none of them are fixed by writing better code. If the previous attempt stopped because one department never gave its data, you now know your dependency risk in week one.

Ask for whatever survived: the repository, the schema, the half migrated table, the document somebody wrote. A partly finished system is a constraint whether you build on it or replace it, and it is often the fastest way to learn what the tricky parts are. When the honest answer is that the old system has to stay alive alongside the new one for a while, that is not a disappointment, it is a plan, and it is best served by small reversible steps rather than one cutover.

5. Who decides when there is disagreement

Ask it plainly: when two people on your side want different things, who decides, and how long does that take. Then ask who has to be consulted before a decision counts, and whether anyone can veto after the fact.

Projects rarely stall on hard problems. They stall waiting for an answer that three people each believe someone else owns. Knowing the name in advance turns a two week stall into a one day one. It also tells you where to send the questions that arrive at the worst moment, when something is half migrated and a choice has to be made today.

If the honest answer is that nobody decides quickly, build for it. Batch the open questions into one short list with a deadline and a default: "if we do not hear back by Thursday we will do X, and it is reversible until the release."

Write the answers down the same day

Within a day, send one page with the same five headings and the answers as you heard them:

Success:      export under 60s on the largest account, measured in the admin panel.
              Failure: still over 3 minutes by the end of the quarter.
Must keep:    nightly invoice job, the weekly report to finance, the partner feed.
Owners:       domain and DNS with the marketing lead, server account with IT,
              payment account owner to be confirmed by Friday.
Tried before: an internal attempt last year, stopped when the data owner changed.
              Old schema still in the database, read only.
Decides:      the operations manager, within two days; finance is consulted for
              anything that changes invoice format.
Open:         who owns the payment account, and can the old schema be dropped.

Plain text, no template, no letterhead. Add one line asking them to correct anything you got wrong, in writing. Corrections are the point, because the version you misheard is the one you would have built.

Bring the same page to every milestone review. When someone remembers the goal differently six weeks later, and someone will, the conversation is about a document rather than about who has the better memory.

What to watch out for

• Asking all five in a rush. Forty minutes of questions with silences in them beats twenty minutes of a checklist being read at someone.
• Accepting an adjective as an answer. Faster, cleaner, more modern and more secure are the openings of questions, not the answers to them.
• Skipping the access question because it feels administrative. It is the single most reliable source of delay in the first month.
• Writing the note as a contract. The moment it reads like a defensive document, people stop correcting it, and a note nobody corrects is worth nothing.

None of these five questions is clever. They work because they force the parts of a project that normally stay implicit into the same conversation, early enough that the answers can still change the plan. Most of the project failures I have watched from close range were not caused by the hard technical problem everyone was worried about, they were caused by one of these five never being asked out loud.