DataGovernance.ca working methods · Original planning guidance. Examples are illustrative, not client results or a regulatory framework.
Bring one disputed term into the room.
Choose a term already causing friction: active customer, qualified lead, completed order or available property. Bring the existing definitions and the decisions they support. Ask each team to explain its current use before trying to agree a replacement. Two different meanings may both be legitimate for different purposes. The goal is not to force every context into one number; it is to make the differences visible and give each definition a clear name.
Separate meaning from implementation.
For each proposed definition, record the business meaning, inclusion and exclusion rules, relevant dates, unit of count and intended audience. Then record how the system currently calculates it. A customer can mean a person, an account or a household; those are not interchangeable counting units. “Active in the last 90 days” also needs a reference date and a qualifying event. An attractive glossary entry cannot repair an ambiguous calculation unless those details are resolved.
Use a time-boxed working agenda.
Here is an illustrative 60-minute format. Spend the first ten minutes on the decision and examples, the next fifteen comparing definitions, fifteen testing boundary cases, ten confirming decision authority and ten recording unresolved items and the next test. Treat this as a planning pattern, not a guaranteed duration. Bring the business owner, a steward or facilitator, a person who knows the calculation and a user of the result. More attendees are not a substitute for an authorised decision maker.
Test the edge cases before announcing agreement.
Use fabricated or approved redacted examples. Ask what happens to duplicate accounts, cancelled orders, late corrections, a person in two systems and an event exactly on the cutoff date. Write the expected answer before running the query. When teams disagree, record the question and the role authorised to decide it. Do not upload customer records to a public worksheet or demonstration just to make an example feel realistic.
Publish a usable definition record.
The record should include a stable identifier, plain-language meaning, purpose, owner role, calculation reference, source systems, exclusions, version, effective date and review trigger. Link to the approved decision and the test evidence. A definition without a known implementation can be marked approved in principle but not yet implemented. Keep old versions where needed to explain earlier reports instead of silently rewriting their history.
Make the next change predictable.
Choose how someone requests a change, who assesses downstream use and who approves it. Tell report users when the definition changes and whether prior periods remain comparable. The steward maintains the record; the business owner retains the decision right; the custodian implements the approved logic. Those responsibilities must be agreed for the organisation rather than inferred from a job title. Revisit the definition when the product, source or business purpose changes.
Start with one concrete example.
Use the related resources to prepare a bounded conversation. Keep confidential records in your approved internal environment.