Prepare a project around one complete piece of work

A useful brief explains what a person needs to accomplish and what the organisation must be able to rely on afterwards. It does not need to begin with a platform choice or a list of every possible feature.

Select a task with a clear boundary: assessing a private-group visit, receiving an order for fulfilment, preparing a field worker's day or maintaining an approved page. Then collect enough evidence to discuss how it works now.

Identify the people and their decisions

Name the person who begins the task and the person who uses the result. For a visit enquiry, the organiser supplies preferences while the operator decides what can be offered. For an internal job, a field worker may record observations while the office approves a changed arrangement.

Also name the people who approve commercial facts, language, access and expenditure. One person may hold several responsibilities, but the proposal should not leave them implicit. A developer can make a decision visible without being authorised to make that decision for the business.

Bring the current sequence

Show the relevant page, document or application and explain what happens next. Include the receiving record or staff process where it can be reviewed appropriately. A screenshot of an empty form does not establish what staff receive after it is completed.

Use anonymised or invented records for the initial discussion. Keep passwords, payment details and private customer files out of ordinary enquiries. If an investigation later requires more sensitive material, agree the purpose, authority and handling arrangement first.

Mark what is known through inspection and what is still assumed. The name of a provider is not evidence that the current account includes a particular interface or permission.

Choose an outcome you could recognise

“Improve the booking process” is broad. “Let an organiser supply two possible dates without either being presented as confirmed, then give staff the same alternatives” is easier to assess.

For a rural order, the result may be that the complete customer-approved destination reaches the receiving record and the packing process. For a maintainer, it may be a reproducible change through the documented publishing or build route. Choose an outcome that can be demonstrated using the actual tools and roles.

Keep unrelated ambitions separate. A clearer enquiry does not automatically require online payment, route planning or a customer portal.

Include the cases that alter the decision

An incomplete request, changed preference, unavailable provider or expired session may reveal more than the perfect demonstration. Choose variations because they affect the intended result.

The organisation should decide what happens when the system cannot resolve a question. It may preserve a draft, request a correction or hand a specific exception to staff. An uncertain result should not become a confident commitment because the design has no space for another state.

The notebook provides worked examples of these investigations and comparisons. Use them to identify the evidence needed for your own task rather than assume the same technical correction applies.

Plan language and remote review

Identify which content needs English, te reo Māori or another language and who supplies suitable review. Include the small text and linked material used in the task. An approved main paragraph cannot compensate for a contradictory button or an unrelated language destination.

Faith Forge Labs delivers remotely from the US. Agree review windows for the actual dates, where decisions will be recorded and who can answer a blocking question. Check clock changes when scheduling. The client remains responsible for approving local requirements and obtaining appropriate specialist advice.

Leave the first discussion with a bounded next step

The outcome may be a proposed website scope, an assessment of an existing system, a provider capability check or a decision to use the current tools more effectively. Record the deliverable, dependencies, decision owner and unresolved questions.

Use the project card for a shorter version of this preparation. When you are ready, send the task and its constraints.