Adopting a best practice should make a real task easier, safer or more reliable, not simply add another document. This checklist shows how to choose one useful practice, test it in your own setting and turn the result into guidance people can actually follow.
How Do You Apply a Best Practice?
Start with a recurring problem, define the outcome you want and choose a practice that plausibly addresses its cause. Run a small, reversible trial, compare results with your starting point and document the version that works. Give it an owner, an exception route and a review date rather than treating adoption as a one-time announcement.
1. Define the problem before choosing the practice
Why: A popular method can be irrelevant to your team's actual difficulty. A daily meeting, for example, will not fix missing access permissions, even if other teams find that meeting useful.
How: Write a short problem statement describing a specific task, who experiences the problem and what happens as a result. Avoid starting with a preferred solution such as “we need a new approval checklist”. Try “customer proposals often return for correction because nobody checks the billing details before sending”.
Choose one primary outcome and one safeguard. For proposal reviews, the outcome could be fewer returned proposals; the safeguard could be avoiding unnecessary delays. Record your current position using available examples, not invented precision. If records are incomplete, say so and start collecting them before the trial.
ISO's quality-management principles include a process approach, improvement and evidence-based decision-making. Those principles support examining the work and its results, rather than adopting a method for its label alone. 1
Keep the first problem small enough to observe. “Improve operations” is too broad; “make the handover from sales to delivery complete” gives you a boundary and identifiable users.
2. Check the fit and the non-negotiable requirements
Why: A practice developed for a large regulated organisation may be excessive for a small team, while a lightweight startup habit may omit controls your work requires.
How: Ask what assumptions the proposed practice makes about volume, staff skills, tools and risk. Separate its essential purpose from its particular implementation. A peer review may be essential; using a specific form or holding it on a particular weekday probably is not.
Use the following screening table before committing resources. It is a decision aid, not a certification checklist.
| Question | Evidence to gather | Decision it informs |
|---|---|---|
| What problem does it address? | Examples of failures or delays | Whether it fits the need |
| Where has it been used? | Source, context and limitations | How much adaptation is needed |
| What must not change? | Applicable rules and contractual duties | Boundaries for experimentation |
| What effort does it add? | Time, tools and training required | Whether the cost is proportionate |
| Can we reverse the change? | Rollback route and dependencies | Safe scope for a trial |
Ask the person responsible for relevant legal, security or compliance obligations to confirm boundaries. A voluntary best practice cannot waive a mandatory requirement. Where interpretation is uncertain, pause the affected part of the trial and seek qualified advice.
3. Assign ownership and design a small trial
Why: Without clear responsibility, a trial can become permanent by accident or disappear before anyone evaluates it. Ownership makes the decision visible without requiring one person to do every task.
How: Name a practice owner, participating users and a person authorised to accept or reject the trial result. In a small team, some roles may overlap; make the overlap explicit. Atlassian's roles-and-responsibilities exercise offers a practical way to surface unclear responsibilities and gaps. 2
Write down the trial's scope, start and review points, success signals and stopping conditions. Choose a bounded workflow, such as one type of proposal, rather than changing every customer interaction at once. Select a duration that includes enough representative work to learn something; do not end the trial just because a convenient date arrives.
Make reversal practical. Keep the previous template available and explain what happens to work already in progress. If the change could affect customer commitments or sensitive information, get the necessary approval before the first live use.
Brief participants on what is being tested. They should know how to report confusion, how much discretion they have and where to get help.
4. Test with real work and record the friction
Why: A process can look complete on paper while failing when information is missing or the usual reviewer is away. Real use exposes these conditions.
How: Walk through one ordinary case before going live, then use the practice on the agreed scope. Keep a lightweight log: date, case type, result, unexpected difficulty and any deviation. Avoid recording sensitive customer details when a reference number or anonymised description is enough.
For example, imagine a small services team testing a proposal review. The proposed practice requires a second person to check scope, price and billing details before dispatch. During the trial, the team discovers that the reviewer cannot see the latest pricing file. The useful response is to fix access and identify the authoritative file, not to blame reviewers for missing a check.
Also record situations where the practice adds no value. An unchanged renewal might need a shorter check than a new bespoke engagement. That observation can justify different paths, provided the team preserves necessary controls.
Distinguish ordinary friction from serious risk. A confusing field can wait for the review meeting; an exposed credential or unauthorised commitment needs immediate escalation through the relevant process.
5. Compare results and make an explicit decision
Why: Enthusiasm, complaints and a successful individual case are useful signals, but none alone establishes whether the practice improves the workflow.
How: Compare the trial with the baseline using the same definitions. Count comparable cases and note differences in workload or case complexity. A quieter period or an unusually experienced participant can make a change appear better than it is.
Review both the main outcome and the safeguard. If fewer proposals return for correction but approvals now stall when one reviewer is unavailable, the process needs adjustment. Consider a backup reviewer or a risk-based review rule rather than declaring uncomplicated success.
Choose one of four outcomes: adopt, revise and retest, extend the trial to answer a specific question, or stop. Record the reason. An inconclusive trial is not a failure if it identifies what evidence is missing.
Invite feedback from people doing the work, not just its managers. Ask which step prevented an error, which step duplicated existing work and which case did not fit. These questions usually produce more actionable information than asking whether everybody “likes the new process”.
6. Publish the working version and maintain it
Why: A useful practice will drift if its instructions, owner and exception rules live only in someone's memory.
How: Create one authoritative page and link to it from the place where people work. Include purpose, scope, prerequisites, steps, completion criteria, owner, version and review triggers. Add a short worked example and explain when users should stop and ask for help.
For the proposal example, completion might mean that a reviewer has checked the current scope, confirmed the price against the authoritative record and recorded approval in the agreed system. “Review done” is too vague to guide a new colleague.
Document permitted variations separately from exceptions requiring approval. State who may approve an exception, what must be recorded and when it expires. Schedule a review, but also trigger one after a significant incident, tool change or change in obligations.
Introduce the practice through a walkthrough, not just an announcement. Ask a colleague who did not write it to follow the instructions on a realistic example. Revise confusing language before extending the practice to more work.
Questions About Applying Best Practices
How many practices should we introduce at once?
Start with one clearly bounded change when possible. Multiple simultaneous changes make it harder to understand what helped and can overwhelm the people learning them. Urgent mandatory controls may need a different rollout plan.
What if we do not have reliable baseline data?
Collect a small, clearly described starting sample and record its limitations. You can also document recurring failure types. Avoid presenting an informal observation as a measured improvement.
Does every practice need a separate policy document?
No. A short checklist inside an existing workflow may be enough. Use a formal policy when authority, organisational scope or mandatory obligations require it; do not confuse document length with control quality.
Who should approve an exception?
Choose someone with the authority and knowledge to accept the relevant risk. That may be the process owner for a minor variation, but security, legal or financial matters may require a specialist decision.
How to Apply Applying Best Practices in Practice
A successful adoption is a tested improvement with clear ownership, usable instructions and a safe way to handle unusual cases. Keep the practice only while its benefits justify its cost and it remains suitable for the work.
Next steps: Read the plain-English overview, check the common adoption mistakes and explore the best-practices hub.
Sources
- ISO — Quality management principles: The foundation for success
- Atlassian — Roles and Responsibilities
This guide is general education, not professional advice.