How It Works

From requirement to accepted work

WARA’s work model is designed to organise the steps between a customer needing something and the agreed work being completed.

The process must work for different kinds of services. A small individual assignment may require only a clear description, an agreed price, and confirmation of completion. A larger production order or multi-location service may need detailed specifications, task allocation, intermediate checks, and coordination among several contributors.

The underlying lifecycle remains consistent even when the level of detail changes.

Requirement → Scope → Agreement → Assignment → Execution → Quality Verification → Acceptance → Settlement

Each stage has a distinct purpose. Moving through these stages helps the parties understand what has been requested, what has been committed, who is responsible, and what must happen before the engagement is considered complete.

This describes the intended operating model. The precise process and available mechanisms depend on the service and the arrangements implemented for the particular engagement.

1. Requirement: Understand what is needed

The process begins when a customer identifies a need for a product, service, or defined outcome.

The initial request may be broad. A customer might need a website updated, equipment installed, garments produced, a property maintained, or a service delivered at a particular location.

Before the work can be organised, the parties need enough information to understand the requirement. This may include:

• The problem to be addressed or the result required.
• The quantity, location, or intended users.
• Relevant specifications or constraints.
• The required timing and any dependencies.
• The resources or access the customer must provide.
• Any safety, qualification, or regulatory requirements.

Not every detail must be known at the first enquiry. The purpose of this stage is to identify what is known, what remains unclear, and what information is needed before a workable scope can be agreed.

An enquiry is not a confirmed order, and submitting a requirement does not guarantee that a suitable provider will be available.

2. Scope: Define the work

Once the requirement is understood, it must be translated into a defined scope.

The scope describes what the assignment includes, what it excludes, and what the customer should expect to receive. It also provides the basis for estimating resources, time, cost, and delivery responsibilities.

Depending on the service, a scope may specify:

• Tasks or deliverables.
• Quantities, dimensions, materials, or technical requirements.
• Milestones and dependencies.
• Completion and acceptance criteria.
• Responsibilities of the customer and provider.
• Assumptions, exclusions, and conditions that could affect delivery.

For example, a request for a batch of uniforms may need to define garment types, sizes, fabric, quantities, finishing requirements, packaging, and delivery arrangements. Without these details, different parties may interpret the same request differently.

The scope should be proportionate to the work. Simple assignments should not require unnecessary documentation, while complex or higher-risk work needs enough detail to manage expectations and accountability.

3. Agreement: Confirm the terms

After the scope has been sufficiently defined, the relevant parties can establish the terms under which the work will proceed.

The agreement should make clear what each party is committing to. Depending on the engagement, this may include:

• The agreed deliverables and acceptance criteria.
• Price, payment schedule, and settlement conditions.
• Expected timing and important milestones.
• Responsibilities for materials, equipment, access, and coordination.
• How changes to the scope will be handled.
• How defects, delays, disputes, or other exceptions will be addressed.

The appropriate form of agreement depends on the nature and value of the work, applicable law, and the parties involved.

A proposal or estimate should not be confused with an accepted engagement. Work should proceed on the basis of the commitments and authorisations required for that particular arrangement.

Clear agreement protects both the customer and the delivery participants by establishing a common reference for execution and later verification.

4. Assignment: Arrange suitable delivery

Once the engagement is agreed, the work can be assigned to an appropriate person, service provider, team, or organisation.

The delivery arrangement should reflect the nature of the work and the capabilities required. A simple task may be assigned to one qualified individual. A larger requirement may need a local provider to organise several workers, or an organisation to coordinate contributions across locations.

Assignment decisions may need to consider:

• Demonstrated capability and relevant experience.
• Required qualifications, licences, or permissions.
• Availability and location.
• Equipment, materials, and other resources.
• Dependencies between contributors.
• Responsibility for coordination and final delivery.

The parties must also understand who is responsible for the overall engagement and how the work will be coordinated.

WARA’s intended Marketplace model can support connections between requirements and suitable delivery capability. The actual assignment depends on availability, suitability, the commercial arrangement, and confirmation by the relevant parties.

5. Execution: Carry out the agreed work

During execution, the assigned people or organisations perform the agreed tasks and manage the resources and dependencies needed to complete them.

The method depends on the service. Some work can be completed independently. Other work requires customer access, material supply, scheduled visits, staged production, specialist input, or coordination between multiple contributors.

Execution should remain aligned with the agreed scope. Where progress updates are needed, the parties should know what information will be shared and when. Changes that affect cost, timing, quality, or responsibilities should be handled through the agreed change process rather than assumed to be included automatically.

For distributed work, coordination becomes especially important. Contributors need clear task boundaries, access to relevant instructions, and an understanding of how their outputs fit into the complete assignment.

The aim is to complete the work in a way that satisfies the agreed requirements while making delays, dependencies, and exceptions visible enough to address.

6. Quality verification: Check the result

Completed work must be checked against the criteria established for the assignment.

The form of verification depends on the service. It may involve a checklist, inspection, measurement, demonstration, testing, review of records, or confirmation that specified tasks have been completed.

For complex assignments, checks may be needed at intermediate stages as well as at the end. Early checks can identify problems before they affect later work.

Verification should be based on the agreed requirements rather than an unstated or newly introduced expectation. Where professional standards, safety procedures, or regulatory requirements apply, the relevant obligations must also be met.

If a result does not meet the criteria, the parties need to identify the gap and determine the appropriate response under the agreement. This may involve correction, further work, revised arrangements, or another agreed resolution.

Verification and acceptance are related but distinct. Verification examines whether the requirements have been met; acceptance is the authorised decision made under the engagement terms.

7. Acceptance: Confirm completion

Acceptance establishes whether the delivered work satisfies the conditions agreed for the engagement.

The responsible party reviews the result and confirms acceptance according to the applicable process. If the work is incomplete or a requirement remains unmet, the outstanding issue should be recorded and addressed under the agreement.

Acceptance criteria should be clear before execution begins. Otherwise, the parties may disagree about whether the work is complete or what additional effort is required.

Some engagements may allow partial acceptance of milestones or separate deliverables. Others may require the entire output to meet the agreed conditions before final acceptance.

The acceptance process should also respect any contractual or statutory rights and obligations. A general description of the WARA lifecycle does not override the specific agreement or applicable law.

8. Settlement: Complete the commercial process

Settlement follows the payment and other commercial conditions established for the engagement.

Depending on the agreement, settlement may be linked to accepted deliverables, completed milestones, verified quantities, recurring service periods, or another defined event.

The relevant records should make it possible to understand:

• What work was agreed.
• What was completed and accepted.
• What amount or payment obligation applies.
• Whether any agreed adjustments or unresolved issues remain.
• What settlement action is due and whether it has been completed.

For assignments involving multiple contributors or service providers, the commercial arrangement should clarify the responsibilities for payments and settlement. Participants should not have to infer these responsibilities from an informal understanding.

The exact payment flow depends on the parties, contracts, and operating arrangements. Participation in the Marketplace should not be taken to imply a particular payment schedule unless that schedule has been agreed.

How the lifecycle changes with the work

The same lifecycle can support different kinds of engagements, but not every assignment needs the same level of process.

These examples illustrate how the model may be applied. They do not establish that every listed service is currently available through WARA.

The governing principle is to use enough coordination to deliver the agreed result reliably without adding unnecessary process to straightforward work.

Responsibilities throughout the engagement

The delivery lifecycle involves different responsibilities, and these should remain clear even when several parties participate.

• The customer explains the requirement, supplies agreed information or resources, and fulfils the obligations established in the engagement.
• The service provider or assigned contributor performs the work it has accepted and follows the applicable requirements and procedures.
• A coordinating organisation, where involved, manages the coordination and delivery responsibilities it has agreed to undertake.
• The party responsible for verification and acceptance applies the relevant criteria and records the outcome according to the agreed arrangement.
• The party responsible for settlement fulfils the payment or other settlement obligations established by the engagement.

One organisation or individual may perform more than one role. The important point is that the responsibilities are explicit and consistent with the agreement.

WARA’s commercial role depends on the particular engagement. It should not be assumed that WARA directly employs every contributor, performs every service, or accepts responsibility for obligations assigned to another participating organisation.

What a well-organised lifecycle achieves

A clear lifecycle helps reduce misunderstandings between customers and delivery participants. It creates a shared reference for scope, responsibilities, execution, quality, and settlement.

It also provides a basis for learning from completed work. Repeated delays may indicate a planning problem. Recurring defects may reveal unclear specifications or a need for additional training. Settlement disputes may point to incomplete agreements or missing records.

These observations can help improve future assignments when they are supported by reliable evidence and appropriate review.

The lifecycle cannot guarantee that every engagement will succeed. Its purpose is to make expectations clearer, responsibilities more manageable, and problems easier to identify and resolve.

The next page explains how the service catalogue should present offerings and distinguish current availability from services that are only proposed or open for enquiry.

Continue with Services.