Turn the development concept into declared assumptions
Record intended use, phasing logic, shared functions, site relationships and the decisions already made. Mark each statement as confirmed, provisional or unknown so the team can see where design work would otherwise rest on an assumption.
Do not use a product image to fill a missing brief. Documented product information can answer product questions later, but it cannot define the developer's land, operating concept or local process.
| Constraint | Evidence | Decision boundary |
|---|---|---|
| Programme input | current state | developer owner |
| Site interface | evidence needed | project owner |
| Supplier information | documented source | review step |
| Decision | dependency | next reviewer |
Give each project phase an entry condition
Define what must be known before concept comparison, site coordination, product review and proposal preparation. An entry condition may be a drawing, decision, survey, local opinion or documented product field. Record the version, owner and review date so later changes do not silently invalidate a decision made at an earlier step.
A phase should not open because the calendar reached a date. It opens when the required evidence exists and the responsible reviewer has accepted its scope.
Split the factory scope from every project interface
Create separate lines for product information, site preparation, access, external works, utilities, local review, installation coordination and operator setup. The list should show dependencies without assigning unverified responsibility.
This boundary makes later proposals comparable. It also prevents a general word such as complete from hiding different exclusions or project-owned work.
Request proof at the same grain as the decision
Ask for the exact information needed to resolve a question: a specific product field, scope statement, project review or documented example with a clear boundary. Broad marketing language cannot close a precise decision.
Use documented project examples only for what their source records. Keep the current development separate unless an exact, reviewed connection is established.
What a developer can expect from QHOME
QHOME can review a complete developer brief against documented product and project information, then state what it can confirm and which inputs remain with the developer or local project team. Missing information stays visible in the response.
Only a written project proposal can define supply scope, phasing assumptions, lead times and price. this guide does not promise supplier scale, product allocation or a delivery programme.