Before the kickoff there is one preparatory alignment meeting with the customer. This time is the story of the few days spent preparing for that day.
The material we produced was six sheets: agenda, proposed team structure, a draft of the approach, items to confirm, demo policy, roles on the day. This kind of material is usuallyfilled with the vendor’s own introduction.Company overview, track record, team, our strengths.
This time we began by cutting that.
We compressed the introduction and secured 15 minutes for listening.
We put the centre of gravity of the agenda on hearing the customer’s conditions for success. When this project ends, what has to be true inside the customer’s organisation for it to be called a success? We secured 15 minutes to hear that in their own words.
To create those 15 minutes, we compressed our own side’s explanation. Track record and the details of the team can be answered when asked.Saying things before you are asked produces nothing in that room.
Failures in requirements definition are usually not missing requirements.They are proceeding without agreement on what counts as success in the first place.Every function built, the deadline met, and still the customer is not satisfied. That shape begins where the first 15 minutes were not taken.
If you are asking for a decision, bring the material for deciding too.
We decided to bring the team structure as two options, because the shape changes depending on who takes project management.
What we were conscious of here was not asking “which would you prefer?”. For each of the two we set out what gets stronger and what gets thinner. What we ask the customer to choose is the conclusion; the comparison itself is our job.
We built the draft approach on the same thinking. We stopped writing it in a way that imposes our standard procedure, and unified the wording around fitting the customer’s own formats and tools. Time spent arguing about the approach is subtracted from time spent nailing down requirements.
We put 16 awkward questions on the table first.
This was the piece of work from this period that paid off most later. We listed, in advance, 16 items we could not proceed without confirming.
The breakdown: 8 to confirm on the day, 6 to confirm during requirements definition, 2 relating to the contract. Some of them were awkward to raise.Can we see real data? Can we get into the development environment? How is personal data to be handled?
These three, left unasked, will jam the project in its second half without fail. A screen designed without seeing real data collapses the moment real data goes in. An integration built without access to the environment does not work on the day you connect it.
Asking the awkward things first is not politeness — it is risk management.
We deliberately held the demo to five minutes.
While preparing, you start wanting to show the whole working prototype on the day. You have the thing you fixed in 82 places sitting right there.
We did not. For the preparatory meeting we decided on a five-minute digest, and only if asked, with the full demo at the kickoff.
There were two reasons. One: the lead role of the preparatory meeting is listening, and starting a demo always eats 15 minutes. Two: showing something that works swings the customer’s expectation towards “it is already done.”.
So we also wrote down the rules for what we disclose. When showing a screen, always distinguish: this is implemented / this is only a screen image / this figure is a reference value. A prototype is a tool for aiding explanation, not proof of completion. Projects that proceed while leaving this vague always end in friction later.
Material sitting on one person’s PC is not an asset.
There was one more unglamorous piece of work in this period. We moved the diagrams that existed only on one member’s PC into a place everyone could use, and organised them.
It happens often that before a meeting, someone produces a clear diagram they made personally. While it stays in that person’s hands,the project’s ability to explain itself drops on the days that person is unavailable.
For the same reason we wrote down the assumptions decided in internal meetings: the estimate of the duration, the number of deliverables, the policy for reporting and issue management.Assumptions everyone believes they agreed on verbally are the ones that wobble latest.
When something works, the moves available in sales change.
Every judgement above looks, at first glance, like “process tweaks that have nothing to do with AI.” In fact they are all connected.
We could cut our own introduction because there was something real to show in place of the explanation. You do not have to talk about your track record if five minutes of a working build conveys your capability. We could resist the demo for the same reason: if you only hold one card, you have to play it in the first round.Because we knew the full demo was possible at the kickoff, we did not have to spend it at the preparatory meeting..
We could ask for real data and environment access at the very start because implementation had already begun. Not as something “that will be needed once design is finished,” but as what we are stuck on today. That is why we could ask concretely.
The conventional early stage became a repetition of “explain, listen, take it away” because the only deliverable was paper. Put AI at the centre so the real thing exists first, andeven the sales stage turns into “show and decide.”The process did not get faster; what happens inside the meeting changed.
Preparation turned out to be the work of designing how the day’s time is spent.
Summed up in one line, what we did over those few days was not producing documents.designing how much of a limited meeting is spent on what.
Cutting the self-introduction, finishing the comparison in advance, putting the awkward confirmations first, resisting the demo. Every one of them was a judgement aimed at shifting the day’s time towards deciding.
Next time: counting what we did not understand and putting it on the table.
* The counts in this article are our own side’s work records. Nothing identifying the customer or the system is included. Approach and time required vary with the scale and structure of the project.
Series “Project Diary” (7 parts)Part 1: 82 fixes to the prototype on the day we won the projectPart 2: Cutting our own company introduction out of the first meeting’s agenda (this article)Part 3: Counting what we did not understand and putting it on the tablePart 4: Bringing the prototype closer to the real buildPart 5: Killing “it looks like it worked but nothing happened”Part 6: Cutting promises we could not keep out of the materialPart 7: Dropping the paper comparison and deciding by measurement