Five things to prepare before a project starts

Working with teams who arrive prepared for a discovery call cuts weeks off a project. Below are five things you can gather beforehand that make a direct difference.

The real benefit of preparation is not speed, it is accuracy. If the need is not understood clearly in the first conversation, scope gets estimated, and estimated scope changes in month three. Changed scope is the most expensive line item in any project.

1. A week of workarounds

For one week, note every moment you work around your current system. Every step you export to a spreadsheet, copy by hand, ask about over chat, or write on paper goes on this list.

That list explains the requirement better than any brief. It also costs nothing to produce.

Next to each line, write two things: how many times a week it happens, and how many minutes it takes. Those two columns get used directly when deciding what goes into the first release. How far can a spreadsheet take you covers how to read the same measurement.

2. Real screenshots and files

Gather the spreadsheet you use now, a screenshot of the dashboard, the form you fill in, the report you produce. Not blank templates, real filled-in examples.

They are the fastest way for us to understand what the data structure needs to be. It is only in a real file that you see the "customer name" column sometimes holding a company and sometimes a person, or the date format written two different ways.

For files with personal data, redact the name and contact columns before sending. The structure needs to be real; the identities do not.

3. Who sees what

How many roles will use the system, and what will each of them see and be able to change? A rough list is enough:

• Manager: everything
• Sales: their own customers
• Accounting: collections only
• Field team: only jobs assigned to them

Permission structure is one of the most expensive things to change later, so it needs discussing up front. The shape of the data model depends directly on this list: whether "their own customers" is defined by user, team, or territory changes the architecture.

4. A list of systems to connect

Which programs do you use? Accounting, e-invoicing, shipping, marketplaces, and email all belong on the list. Write the product names with version information and a link to API documentation if you have one.

Integrations produce more surprises than any other part of a project. Simply knowing the product name lets us give a clear answer in the first conversation: whether it has an API, whether it can export, or whether it has to be read through the interface.

Answer one more question alongside it: which way will the data flow? There is a significant difference in effort between a one-way transfer and a two-way sync. What is API integration explains that difference in detail.

5. The measure of success

What do you expect to have changed when this project is finished? One sentence is enough, but make it concrete:

• "Quote preparation should take half as long."
• "The month-end report should not be assembled by hand."
• "The field team should not carry paper."

That sentence becomes the referee for scope arguments throughout the project. If a feature does not serve it, it does not need to be in the first release.

When you write the sentence, note today's value too. Without "quote preparation currently takes about 40 minutes," you cannot say it was halved.

What you do not need to know

You do not need to prepare any of these, because they are our job:

• Which technology will be used
• How the database will be structured
• Where the server will sit
• What the screens will look like
• How many people will work on it and how the work will be split

We do not expect technical decisions from you. The only thing we need is how the work actually runs.

There is one exception: if you have a constraint about where the data has to live, say so at the start. A requirement such as in-country hosting affects the architecture from day one.

Who should be at the table

This is the most-skipped part of the preparation. Two people should be in the discovery call: the person who does the work daily, and the person who can make decisions.

If only the manager joins, the details of the process stay incomplete. If only the user joins, scope decisions get deferred. When both are in the same room, the conversation usually finishes in one session.

What the preparation buys you

For projects that arrive with the list ready, discovery closes in one conversation. Without it, the same stage takes two to four weeks, because information has to be gathered internally for every question.

The difference is not only time. Prepared teams end up with a narrower and clearer first release, which makes the whole project cheaper.

---

If you have these five ready, let's set up a discovery call. Most of the scope usually becomes clear in that first conversation.