The short answer
The preparation that matters is not technical. It is knowing how the work is actually done today, who can decide things during the build, and what condition your data is in.
A supplier can discover all three, slowly and at your expense. Knowing it beforehand shortens everything.
Document the process as it is
- Write down the steps as they actually happen, not as the policy says.
- Include the workarounds, because they exist for reasons.
- Note who does each step and what they need to know.
- Note the exceptions and roughly how often they occur.
- Have the people who do the work check it.
Point two is where the real requirements hide. Every workaround is either a gap in the current system or a rule nobody wrote down.
Decide who decides
| Decision | Needs an owner |
|---|---|
| Scope changes | One person who can say yes or no |
| Process changes | Whoever owns the process |
| Data handling | Whoever is accountable for it |
| Acceptance | Whoever will live with the result |
| Budget | Someone available within days, not weeks |
A project waiting a fortnight for a decision is paying for the wait. Name the people before the work starts.
Look at your data honestly
- Where it lives and in what format
- How much of it is duplicated or inconsistent
- Whether anyone maintains it
- Whether it can be exported without asking a vendor
- What would have to be cleaned before it could be used
Data cleaning is the cost most commonly discovered halfway through a project. Discovering it early makes the estimate real.
Be clear about what success looks like
Write down what would have to be true a year after launch for the project to have been worth it. Make it specific enough to check.
If nobody can write that, the project is not ready to start, whatever the technical plan says.