By David Bowman, creator of the DCA philosophy and co-founder of ZEBSOFT
A requirement has little value if people cannot understand it or establish whether it has been met.
That is the starting point for Define–Communicate–Assure (DCA): a practical philosophy for making expectations clear, helping people act on them and checking that the intended outcome has been achieved.
It applies to everyday work, customer commitments, training, supplier management and the use of AI. The subject may change, but the three questions remain:
- Have we defined what is needed?
- Have we communicated it so people understand?
- Can we demonstrate that it happened?
Define: Be clear about what is needed
Start by describing the intended outcome and what an acceptable result looks like.
A useful requirement should be relevant, achievable and clear enough for someone to act on. Consider who will carry out the work, what they need to know and how the result can be checked.
Definition must take communication and assurance into account from the beginning. If a requirement cannot be explained or verified, it needs reconsidering.
For example, “make sure suppliers are suitable” leaves people to decide what suitability means.
A clearer requirement would be:
Before placing an order, confirm that the supplier can meet the specification, delivery date and any required approval conditions.
That gives the person something specific to establish. The level of detail should reflect the importance and consequences of the purchase.
Communicate: Make sure people understand
Make sure the people doing the work understand what is expected, why it matters and what to do if they cannot meet the requirement.
Publishing a procedure or sending an email does not establish that someone understands it. Communication needs to suit the person and the task.
A short demonstration may work better than a lengthy document. A clear instruction at the point of use may be more useful than a policy stored elsewhere. Some tasks need training and an opportunity to practise.
In the supplier example, the person placing the order needs to know which checks apply, where to find the information and who to ask if something is missing.
Communication also needs to work in both directions. People should be able to question an unclear instruction or explain why a requirement does not work in practice.
If people cannot sensibly apply what has been defined, their feedback should help improve it.
Assure: Establish whether it happened
Check that the requirement has been met using evidence appropriate to the task.
That could mean inspecting a result, observing someone carrying out the work, reviewing a record or checking that a customer commitment has been fulfilled.
For the supplier example, evidence might include a confirmed specification, an agreed delivery date and a current approval record.
A tick in a box may record that someone completed a check. Its value depends on what they actually checked and whether the result supports acceptance.
Assurance should also lead to action. If the requirement has not been met, establish what needs correcting, who will deal with it and whether the definition or communication contributed to the problem.
Check what matters
DCA should help organisations avoid unnecessary checking.
The depth of assurance should reflect the value of the outcome and the consequences of getting it wrong. Routine, low-impact work may need a simple check. Work affecting safety, significant customer commitments or business continuity may need more substantial evidence and competent review.
Before introducing a check, ask:
What decision will this evidence support, and what will we do if the result is unacceptable?
If neither answer is clear, reconsider whether the check serves a useful purpose.
Applying DCA to AI-generated work
AI provides a useful example because a polished answer can appear ready to use before anyone has established whether it is correct.
Consider an employee using AI to draft a tender response.
| DCA principle | Practical application |
|---|---|
| Define | The response must accurately describe what the organisation can deliver. Material claims must have supporting evidence. |
| Communicate | Explain that the employee must check those claims and refer anything they cannot confirm to the responsible person. |
| Assure | Have a competent person review the response against the evidence, resolve unsupported claims and approve it before submission. |
The organisation can benefit from AI while retaining responsibility for the work it accepts and uses.
The same approach applies when a person writes the response without AI. The need for accurate commitments and supporting evidence remains.
Responsibility needs understanding
People are better placed to take responsibility when they understand the outcome, have the means to achieve it and can raise concerns.
DCA encourages that involvement. Those doing the work can help identify unclear requirements, impractical instructions and checks that add little value.
When something goes wrong, the three principles also provide useful questions:
- Was the requirement clear and achievable?
- Did the person understand it and have the necessary information?
- Were the checks capable of identifying the problem?
The answers help an organisation improve the conditions in which people work, as well as address the immediate failure.
How ZEBSOFT supports DCA
DCA is a philosophy developed by David Bowman. ZEBSOFT is authorised to use it and provides tools that can support its practical application.
Controlled documents and workflows can define requirements. Tasks, instructions and training can communicate them. Completed records, linked evidence, reviews and corrective actions can support assurance.
ZAP workflows can bring these elements together for a simple check or a more complex process. Organisations can configure the workflow themselves or have ZEBSOFT configure it with them.
The value comes from making the requirement, the work and the evidence traceable.
Start with one real task
Choose a recurring activity where uncertainty, mistakes or unnecessary checking cause problems.
Write down the intended outcome. Ask the person doing the work to explain what they understand is required. Then look at the evidence you use to decide whether the result is acceptable.
Any gap gives you a practical place to begin.
Define what matters. Communicate it clearly. Assure that it happens.
Book a ZEBSOFT demonstration to explore how DCA can be supported through practical workflows and linked evidence.

