Delivery Model
WARA’s delivery model is intended to turn a customer requirement into a clearly defined assignment. The model establishes what must be delivered, who is responsible, how quality will be assessed and how payment will be handled under the agreed terms.
From Requirements to Deliverables
A service category describes the kind of work that may be performed. A delivery model explains how a particular assignment is organised and completed.
For a customer, the objective is to receive an agreed result with clear expectations about scope, timing, quality and cost. For a service provider, the objective is to understand the responsibility, resources, acceptance criteria and payment conditions before committing to the work.
WARA’s intended delivery model is built around a simple principle: define the assignment before expecting the result.
The level of coordination depends on the work. A small, self-contained task may need only a short specification and a clear handover. A larger assignment may require multiple providers, milestones, progress reviews and formal acceptance.
The Assignment Lifecycle
A typical assignment can be organised into the following stages.
1. Requirement and Scope
The customer explains the need, expected result, relevant constraints and any deadline.
The requirement is then translated into a workable scope. This should clarify what is included, what is excluded and what information or resources are needed to begin.
Where important details remain uncertain, they should be resolved before a delivery commitment is made.
2. Delivery Arrangement
The assignment is matched with an appropriate provider or delivery team, taking account of relevant skills, experience, availability, location, equipment and other requirements.
For work involving several people or organisations, responsibilities and coordination arrangements should be established in advance.
A potential provider match is not, by itself, a confirmed engagement. The assignment proceeds only when the relevant parties have agreed to the arrangement.
3. Commercial Agreement
The parties establish the commercial terms before work begins.
Depending on the assignment, these may include:
- Price and payment schedule
- Start date, milestones and delivery deadline
- Materials, equipment and other agreed costs
- Customer responsibilities and dependencies
- Changes to scope and their effect on cost or timing
- Quality requirements and acceptance conditions
- Treatment of delays, rework, cancellation and disputes
The agreement should be proportionate to the assignment. A routine task does not need the same documentation as a complex, multi-stage project.
4. Execution and Coordination
The provider performs the agreed work. Where coordination is required, the responsible parties track progress, resolve dependencies and communicate material changes.
If the customer changes the requirement or a delivery constraint arises, the effect on scope, cost, timing or quality should be discussed rather than silently absorbed into the original assignment.
5. Quality Verification
The completed work is checked against the criteria agreed for the assignment.
Verification may involve inspection, testing, review of documents, confirmation of quantities or another method appropriate to the deliverable.
The criteria should be understandable before execution begins. This reduces the risk of disagreement about whether the work is complete.
6. Acceptance and Handover
The customer or designated authorised party reviews the deliverable and confirms whether it meets the agreed acceptance criteria.
If it does not, the parties should identify the specific gaps and determine the appropriate next step under their agreement.
Acceptance and quality verification are related but distinct. A provider may perform an internal quality check, while formal acceptance may remain the customer’s responsibility.
7. Settlement and Closure
Payment is handled according to the agreed commercial terms and the applicable completion, milestone or acceptance conditions.
The assignment can then be closed with the necessary handover, records and follow-up actions.
The exact settlement process depends on the agreement. The delivery model does not imply that every assignment uses the same payment schedule or that a particular digital settlement system is already operational.
Responsibilities in a Delivery Arrangement
Clear responsibility helps prevent tasks from being overlooked or assumed to belong to someone else.
| Participant | Typical responsibility |
|---|---|
| Customer | Defines the requirement, supplies agreed inputs, reviews deliverables and fulfils agreed obligations. |
| Service provider | Performs the assigned work, communicates progress and delivers against the agreed scope. |
| Delivery coordinator, where appointed | Coordinates people, schedules, dependencies and communication across the assignment. |
| Quality reviewer, where required | Checks the work against the specified criteria. |
| Commercial operator, where applicable | Handles the responsibilities assigned under the commercial arrangement, which may include customer coordination, assignment administration or payment-related processes. |
These are functional roles, not a requirement for five separate participants. One person or organisation may perform several roles in a small assignment. Responsibilities should nevertheless remain explicit.
Quality, Acceptance and Rework
Quality must be defined in terms that fit the work.
For a document, this might mean completeness, accuracy and an agreed format. For an installation, it might include specified functionality, safe operation and completion of agreed checks. For a production assignment, it might include dimensions, quantities, material specifications and permissible defects.
A sound assignment should distinguish between:
- Completion: The provider has performed the specified work.
- Verification: The work has been checked against the agreed requirements.
- Acceptance: The authorised party confirms that the deliverable meets the agreed conditions.
- Rework: Identified deficiencies are addressed according to the agreement.
The responsibility for rework, its limits and any additional costs should be agreed where relevant. These conditions should not be left entirely to assumptions after delivery.
Different Assignments, Different Levels of Coordination
The same basic principles can support different delivery arrangements.
| Assignment type | Typical coordination approach |
|---|---|
| Simple individual task | Defined scope, one responsible provider, clear deliverable and straightforward acceptance. |
| Recurring service | Agreed service scope, schedule, performance expectations and periodic review. |
| Production or batch work | Specifications, quantities, quality checks, deadlines and handover arrangements. |
| Multi-provider assignment | Defined responsibilities, dependencies, coordination and consolidated acceptance where appropriate. |
| Complex project | Detailed scope, milestones, documented changes, risk management and staged acceptance. |
These are examples of how the model may be applied. The actual arrangement should be selected according to the requirements and risks of the work.
The Role of WARA
WARA Systems is intended to support the commercial work ecosystem, including customer engagement, assignment coordination, provider networks and delivery organisation where applicable. The precise role depends on the service and the agreement among the parties.
The Wara KarmaYoga Foundation Trust has a separate social and educational role, including training, outreach and livelihood preparation. Training may help people develop capabilities for future work, but a training participant is not automatically an assigned provider, and completing a course does not guarantee work.
The wider ecosystem is intended to create a more organised path between skills, customer demand and work delivery. Its practical value depends on suitable providers, clear requirements, realistic commitments and reliable execution.
What This Model Does Not Promise
A defined delivery process can reduce ambiguity, but it cannot eliminate every operational risk.
It does not guarantee that every requirement can be fulfilled, that a suitable provider will always be available, that every deliverable will be accepted or that work will generate a particular income. These outcomes depend on the assignment, the parties, the applicable terms and actual execution.
Any service offered to a customer should therefore be based on confirmed capacity and a specific agreement, rather than on the general description of the WARA model.
See the Model in Practice
The next page presents illustrative scenarios showing how the delivery model may apply to different types of work. These examples explain possible arrangements; they should not be interpreted as evidence that every illustrated service or workflow is already operational.
Continue with Examples.