None of this is a formality. Each item shortens Diagnose by roughly the time it would otherwise take us to chase it down.
You don't need everything below perfectly organised before we start; Diagnose exists partly to fill the gaps. But the more of this you have ready, the faster the first stage moves, and the more accurate the resulting plan is.
You don't need a finalised list of customisations, a completed data-cleansing pass, or firm sign-off from every stakeholder before Diagnose starts. Those are exactly what Diagnose and Design are for. Trying to fully prepare them yourself first usually just duplicates work we'd do properly with you anyway.
If system access takes a week to arrange, or a key stakeholder is genuinely unavailable for the first fortnight, we'll say so plainly and adjust the plan rather than quietly working around gaps and hoping they close themselves. The honest answer is usually a short delay to Diagnose's start, not a compromised result.
Send it as-is. Messy real data is more useful to us at this stage than a clean sample that doesn't reflect what your system actually contains.
Usually, yes, and it's worth starting that conversation early since IT approval cycles are one of the more common causes of a slow start.
Roughly two to four hours a week from the people directly involved, concentrated in interviews and reviewing what we've found, not open-ended availability.
Tell us upfront. We'll sequence Diagnose around their actual availability rather than assuming a level of access that isn't real.
Yes, with an honest adjustment to the plan. We'd rather start with a realistic view of what's missing than pretend readiness that isn't there.
Tell us what you have and what you don't. We will tell you honestly what that means for a realistic start date.
With someone who has run this before.
The six stages this page fits into, end to end.