DG Assigment 1 Guide
Capstone Project • Deliverable 1 • Instructor Guide
Governance Framework (DAMA-DMBOK) — Worked Solution
How data governance is applied in a real organisation • five sections • interview practice
How to use this guide
This guide walks through a worked solution for each of the five sections of Deliverable 1. Use it in live class to show how DAMA-DMBOK theory is applied inside a real organisation, and to turn the capstone into a project story you can tell in interviews. The worked answers are one strong approach, not the only right one — challenge them and improve them.
How we use it in class
- Attempt the section on your own or in a small group first.
- Walk through the worked answer, asking why each choice fits this client.
- Use the teaching notes to connect the theory to the client’s facts.
- Close each section with the interview angle: practise explaining your work out loud in about 60 seconds.
Section 1Principles, Policies & Standards
A strong answer picks principles that directly answer the client’s listed challenges: no accountability, conflicting definitions, poor quality, and AI using ungoverned data. Four model sets are shown below; only three are needed. Any three of these, or equivalent sets, would work for the client.
Principle 1 — Data is an enterprise asset with clear accountability
Policy: Data Ownership & Stewardship Policy. Every priority data domain and Critical Data Element (CDE) must have a named Data Owner, Data Steward and Data Custodian, approved by the Data Governance Council.
| Standard | Enforceable rule |
|---|---|
| 1.1 | No CDE may be used in an executive or regulatory report until it is registered in the Microsoft Purview catalogue with a named owner, steward and approved definition. |
| 1.2 | Owner and steward assignments are reviewed every 12 months, and reassigned within 30 days of a role change or departure. |
Linkage: The principle states that data belongs to the enterprise, not to a system or business unit. The policy turns that into named accountability. The standards make accountability visible (Purview registration) and keep it current (review cycle). This answers the brief’s gap “ownership and stewardship unclear.”
Principle 2 — One shared meaning for business data
Policy: Business Glossary & Metadata Policy. Enterprise business terms are defined once, approved by the Data Governance Council, published in the Purview glossary, and used in all enterprise reporting.
| Standard | Enforceable rule |
|---|---|
| 2.1 | Every glossary term must include: definition, Data Owner, Data Steward, calculation rule, source system, and approval status. Draft terms may not be used in executive reports. |
| 2.2 | Executive and regulatory Power BI reports must draw only from certified datasets in the Fabric Data Warehouse that map to approved glossary terms (for example Active Client, Assets Under Management, Investment Portfolio). |
Linkage: The principle targets conflicting executive figures. The policy creates a single authority for definitions. The standards set the minimum content of a definition and force reports to use it. This answers “business units define terms independently” and “glossary kept in spreadsheets.”
Principle 3 — Data quality is measured and fit for purpose
Policy: Data Quality Management Policy. CDEs must have documented quality rules and thresholds, be measured on a fixed schedule, and have issues routed to the accountable steward.
| Standard | Enforceable rule |
|---|---|
| 3.1 | Format rules: emails must pass a valid email format check; country values stored as ISO 3166-1 alpha-2 codes (e.g. CA, US); all dates stored as ISO 8601 (YYYY-MM-DD). |
| 3.2 | Data quality thresholds. Proposed thresholds, measured monthly:
Breaches must be escalated to the relevant Data Steward within 5 business days. These thresholds are illustrative and must be validated against baseline data quality, business requirements and risk before approval. |
Linkage: The principle says quality must be fit for the decision or model using it. The policy requires rules and measurement. The standards fix the exact defects named in the brief: invalid emails, inconsistent country values, mixed date formats, missing tax data, incomplete advisor assignments and duplicates.
Principle 4 (alternative) — Data is protected and used only for approved purposes
Policy: Data Classification & Acceptable Use Policy (including AI). All client data and documents are classified by sensitivity, and access and use (including AI/ML) must match the classification and an approved purpose.
| Standard | Enforceable rule |
|---|---|
| 4.1 | All client data and documents carry a Purview sensitivity label (Public, Internal, Confidential, Restricted). Tax IDs and identification documents are Restricted. |
| 4.2 | AI/ML models must use approved, appropriately classified, quality-assessed data sources that meet the governance requirements of the intended use case. Direct access to ungoverned raw data is prohibited. |
Linkage: The principle protects clients and the firm. The policy sets requirements for data classification, access and responsible use. Standard 4.2 addresses the client’s AI governance gap by requiring AI/ML solutions to use approved, governed data sources. These may include curated data in the Fabric Lakehouse, the Data Warehouse or other approved environments, provided the data meets the requirements of the use case. It directly fixes the brief’s dashed line: today the AI pilot reads the raw, uncurated Lakehouse layer.
Teaching notes
- Theory link: In DAMA-DMBOK, principles guide, policies direct and standards enforce. A principle with no standard behind it never changes behaviour.
- Discussion: “Which client challenge does each standard fix?” Trace every standard back to the brief.
- Discussion: Look at the dashed line in the data flow diagram. Why is an AI pilot reading raw Lakehouse data a governance problem, and which standard stops it?
- Practice: Take a vague statement such as “data should be accurate” and rewrite it as a testable standard with a format, number or deadline.
In an interview
“I built a policy framework for a financial services firm that had grown through four acquisitions. To stop conflicting executive figures, I set a standard that executive reports could only use certified datasets mapped to approved glossary terms.”
Section 2Governance Domains & Roles
The model answer uses seven domains built from the brief’s eight data entities (Product is grouped with Transactions). Owners are Director level, with VPs acting as executive sponsors; stewards are the hands-on business roles closest to the data; custodians come from Technology. You may choose fewer priority domains (for example 4–5) if you state that the rest follow in Phase 2.
Domain summary
| Domain | Description | Data Owner | Data Steward | Data Custodian |
|---|---|---|---|---|
| Client | Core client identity and contact data across Salesforce and the Onboarding Application | Director Client Operations | Manager Client Onboarding | Manager CRM Systems |
| Client Documents | KYC documents, agreements and ID documents collected at onboarding | Director Regulatory Compliance | KYC Specialist | Director Enterprise Applications |
| Portfolio & Holdings | Portfolios, holdings and valuations in the Portfolio System | Director Wealth Operations | Manager Portfolio Administration | Database Administrator |
| Investment Transactions & Products | Transactions and product classifications in the Investment Platform | Director Investment Operations | Senior Investment Operations Analyst | Director Enterprise Applications |
| Advisor & Assignment | Advisors and their client assignments | Director Wealth Operations | Manager Advisor Services | CRM Administrator |
| Benefits Enrollment | Members, plans, eligibility and status in the Benefits System | Director Benefits Operations | Senior Benefits Administrator | Director Enterprise Applications |
| Access & Entitlements | Who (including external advisors) can access which data | Chief Information Security Officer | Manager Compliance | Microsoft Purview Administrator |
Functions and reasons per role
Client
| Role | Two functions | Reason |
|---|---|---|
| Owner: Director Client Operations | Approves the definition of Active Client; sets the duplicate-reduction target and match rules | Runs client operations day to day, with authority over the onboarding and client services teams that create and fix client records |
| Steward: Manager Client Onboarding | Reviews and merges suspected duplicate records; monitors email, country and Tax ID quality | Closest to where client data is created, so defects are fixed at source |
| Custodian: Manager CRM Systems | Configures Salesforce validation rules (email format, ISO country picklist); runs deduplication jobs | Runs the CRM platform where most client records live |
Client Documents
| Role | Two functions | Reason |
|---|---|---|
| Owner: Director Regulatory Compliance | Sets retention periods for KYC and ID documents; approves the classification scheme | KYC documents exist for regulatory reasons, so compliance holds the accountability |
| Steward: KYC Specialist | Checks documents are named, complete and correctly classified; flags unlabelled sensitive files | Works with these documents daily during KYC checks |
| Custodian: Director Enterprise Applications | Applies retention and storage controls in the custom Onboarding Application; supports Purview scanning of document storage | The Onboarding Application is a custom enterprise application |
Portfolio & Holdings
| Role | Two functions | Reason |
|---|---|---|
| Owner: Director Wealth Operations | Approves the definitions of Portfolio Value and Investment Portfolio; resolves cross-system valuation disputes | Leads wealth operations, including portfolio administration, so has both the authority and the working knowledge to settle valuation rules |
| Steward: Manager Portfolio Administration | Documents the valuation calculation rule; reconciles portfolio values across systems | Manages day-to-day portfolio administration and knows how values are derived |
| Custodian: Database Administrator | Maintains the Portfolio System database, backups and access; implements agreed calculation logic | Holds technical control of the database layer |
Investment Transactions & Products
| Role | Two functions | Reason |
|---|---|---|
| Owner: Director Investment Operations | Approves the product classification scheme; signs off transaction data used in regulatory reports | Directs the investment operations and administration teams that process transactions and maintain products |
| Steward: Senior Investment Operations Analyst | Corrects misclassified products; enforces the ISO 8601 date standard on transaction feeds | Senior analyst who works with transactions and products daily |
| Custodian: Director Enterprise Applications | Configures Investment Platform validation (date formats, product codes); manages platform changes | The Investment Platform is an enterprise application |
Advisor & Assignment
| Role | Two functions | Reason |
|---|---|---|
| Owner: Director Wealth Operations | Sets the rule that every active client has an assigned advisor; approves the assignment status values | Runs wealth operations, where advisor coverage is managed |
| Steward: Manager Advisor Services | Monitors unassigned clients weekly; corrects incomplete assignments | Manages advisor services directly |
| Custodian: CRM Administrator | Maintains assignment fields and required-field rules in Salesforce; keeps assignments in sync with the Portfolio System | Administers the CRM configuration where assignments are held |
Benefits Enrollment
| Role | Two functions | Reason |
|---|---|---|
| Owner: Director Benefits Operations | Approves the standard list of eligibility and status values; owns benefits data quality targets | Runs benefits operations and administration, where enrollment records are created and maintained |
| Steward: Senior Benefits Administrator | Maps legacy status values to the approved list; reviews eligibility exceptions | Handles enrollment records daily and knows the legacy variations |
| Custodian: Director Enterprise Applications | Applies picklists and validation in the Benefits System; manages data migration fixes | The Benefits System is an enterprise application |
Access & Entitlements
| Role | Two functions | Reason |
|---|---|---|
| Owner: Chief Information Security Officer | Approves access policy by sensitivity label; owns the entitlement catalogue | Accountable for cybersecurity, a stated strategic priority |
| Steward: Manager Compliance | Runs quarterly access reviews, including external advisors; confirms access matches approved purpose | Compliance must evidence who can see client data |
| Custodian: Microsoft Purview Administrator | Maintains sensitivity classifications and relevant access metadata in Microsoft Purview; coordinates with application and security administrators to support access governance and reporting | Microsoft Purview supports metadata management, data classification and aspects of data security governance. However, actual access controls may be administered through other enterprise systems. The operational custodian responsible for those access-management systems must be confirmed (assumption: no such role appears in the org chart). |
Teaching notes
- Theory link: Owner = accountable and sets the rules; Steward = responsible for meaning and quality day to day; Custodian = runs the technical environment.
- Why Directors are recommended for this client: Data Owners must have sufficient business authority to make decisions about data definitions, quality requirements, access and issue resolution. For this client, Directors are reasonable choices because they have decision-making authority and are close to business operations. VPs can provide executive sponsorship and support escalation.
- Can Managers or VPs be Data Owners? Yes. Data ownership is determined by business accountability and decision-making authority, not job title alone. Depending on the organisation’s structure, Data Owners may be executives, directors or managers. The important consideration is whether the individual has the authority to make and enforce governance decisions, including settling disputes between teams, such as two business units defining Active Client differently.
- The exception: The org chart has no Director-level security role, so the CISO owns Access & Entitlements. State this as an assumption.
- Real-world point: Organisations rarely hire new governance staff at the start. They assign accountability to existing jobs, which is why the brief insists on real org-chart titles.
- Discussion: Why is Technology the custodian and never the owner of business data? Why should stewards sit close to where data is created?
- Discussion: Debate the alternatives, such as the Chief Compliance Officer owning Client Documents, or a Data Engineer as custodian for data in Fabric.
- Extension: Add a Finance domain (Owner: Controller, Steward: Financial Reporting Analyst, Custodian: BI Developer) and explain how it supports regulatory reporting.
In an interview
“I mapped seven data domains to existing roles from the client’s org chart. For client data, the Director Client Operations was owner, the Manager Client Onboarding was steward, and the Manager CRM Systems was custodian. I deliberately kept VPs as executive sponsors rather than owners, because owners need to be close enough to the work to make and enforce day-to-day decisions.”
Section 3Operating Model
The recommended answer is a federated model: enterprise-wide standards set centrally, with ownership and stewardship carried out inside each business unit.
Model answer
Recommendation: Federated (hub-and-spoke) data governance.
Justification from the brief
- Structure: Five business units, 38 offices across Canada and the US, and four acquisitions, each bringing its own systems. Domain knowledge sits in the business units, so stewardship must sit there too.
- Culture: Business units currently define terms independently. A fully centralised model would meet resistance and lack the business context to define terms like Assets Under Management. A decentralised model would simply formalise today’s problem.
- Goals: Regulatory reporting, conflicting executive figures and AI readiness all need enterprise-wide definitions and standards. The shared platforms (Microsoft Fabric, Purview, Power BI) already give the client a natural central hub.
Proposed structure (assumption: no Chief Data Officer exists, so the COO sponsors the program)
| Tier | Members (from the org chart) | Role |
|---|---|---|
| Executive Steering Committee | COO (chair), CFO, CIO, Chief Risk Officer, Chief Compliance Officer, CISO, plus business unit VPs as domain sponsors | Sponsors the program, approves funding and policies, resolves escalations |
| Data Governance Council (hub) | Domain Data Owners (Directors), Director Enterprise Architecture, Director Data Engineering, Director Regulatory Compliance | Approves glossary terms, standards and CDEs; sets priorities; meets monthly |
| Domain stewardship (spokes) | Data Stewards in each business unit | Apply standards, fix data quality issues, maintain definitions for their domain |
| Technical custodians | Manager Data Platform, Database Administrator, CRM Administrator, Purview Administrator | Implement controls, scanning, lineage and quality rules in the platforms |
Trade-offs accepted
- Slower decisions than a centralised model, because cross-domain terms need council agreement.
- Stewards spend part of their working time on governance, which business units must release.
- Risk of uneven adoption between business units, managed through shared KPIs reported to the Steering Committee.
How it improves coordination, accountability and scalability
- Coordination: One council and one glossary in Purview replace five independent sets of definitions.
- Accountability: Every domain has a named owner who reports quality KPIs to executives.
- Scalability: New domains or future acquisitions plug in as additional spokes using the same standards and Purview setup.
Teaching notes
- Theory link: Compare the three DAMA-DMBOK models side by side, then ask which one fits the client’s facts rather than which is “best”.
- Discussion: What would go wrong here with a centralised model? With a decentralised one?
- Real-world point: Most multi-business-unit financial firms run a federated model. Many start more centralised for the first phase, then hand stewardship to the business units.
- Discussion: The client has no Chief Data Officer. Who should sponsor the program, and why does sponsorship matter?
In an interview
“I recommended a federated model because the client had five business units and four acquired legacy systems, but needed one set of enterprise definitions. The trade-off was slower decisions, which we managed with a monthly council and shared KPIs.”
Section 4Importance of Data Governance
The model answer below is written for a non-technical executive and answers all four questions in two paragraphs.
Model answer
Our strategy depends on data we can trust, and today we cannot. After four acquisitions, the same client can appear several times across our systems, and terms like “Active Client” and “Assets Under Management” mean different things in different business units. That is why executive reports show conflicting figures. Data governance gives every critical data domain a named business owner, one approved definition for each key term, and measured quality targets. That directly supports our priorities: a single view of each client improves customer experience, fewer manual reconciliations raise operational efficiency, and consistent figures make regulatory reporting faster and defensible. Without governance, we keep paying for duplicate work and conflicting numbers, and we carry real exposure: inaccurate regulatory filings, privacy breaches from unclassified client documents, and failed KYC and AML checks when client data is incomplete.
Governance is also the gate to our AI ambitions. Our AI advisory pilot currently reads raw data that has not been checked, defined or classified. A model trained on duplicated, poor-quality data will give clients confident but wrong advice, and may expose sensitive data it should never see. Regulators in both Canada and the US expect firms to protect client information, keep accurate records, and explain how automated decisions are made. Governed data — catalogued, classified and lineage-traced in Microsoft Purview — is how we show that control. Across financial services, firms that govern their data are the ones moving AI from pilot to production safely. Funding this program is not an IT cost; it is the foundation for every growth, efficiency and AI goal the Board has approved.
What to cover
| Question | Key points |
|---|---|
| Supports strategic goals | Links governance to at least three of the six priorities (customer experience, efficiency, regulatory reporting, cybersecurity, AI advisory, trusted data foundation) |
| Risks of not governing | Conflicting executive figures, regulatory misreporting, privacy breaches, KYC/AML failures, wasted reconciliation effort, reputational harm |
| Enables analytics and AI | Trusted, defined, quality-checked, classified data; stops the pilot reading raw Lakehouse data; lineage makes AI outputs explainable |
| Regulations and trends | Names relevant regimes for a Canada–US wealth firm (see below) and at least one industry trend |
Regulatory frameworks that may be relevant
The following are examples of regulatory frameworks that may be relevant to the client. Their applicability must be confirmed based on the client’s legal entities, business activities, licences and jurisdictions.
- Canada: PIPEDA and Quebec’s Law 25 (privacy); PCMLTFA and FINTRAC requirements (AML/KYC); CIRO and provincial securities regulators (investment dealer and adviser requirements); and OSFI Guideline E-23 (model risk management for institutions within its scope).
- United States: SEC and FINRA record-keeping and conduct requirements; Regulation S-P (protection of customer information); the Gramm-Leach-Bliley Act; Bank Secrecy Act / FinCEN AML requirements; and applicable state privacy legislation.
- Industry trends: AI-enabled financial advisory services, increased focus on data lineage and explainability, stronger data protection expectations, and the integration of data following mergers and acquisitions.
Teaching notes
- Real-world point: Executives fund outcomes, not frameworks. Notice how the model answer avoids jargon and ties every point to a business goal.
- Practice: Deliver the case as a 90-second pitch to a classmate playing the CFO, who pushes back on cost.
- Discussion: Which risk would worry this client’s Board most, and why?
In an interview
Interviewers often ask “How would you convince leadership to invest in data governance?” Use this structure: strategic goals, cost of doing nothing, AI readiness, regulation.
Section 5Six-Month Value
A strong answer gives each outcome a baseline, a target, a measure and a funding argument, and ties it to the brief’s “What success looks like” list. Targets below are illustrative; baselines are measured in month 1 (assumption: no current baseline exists).
Model answer
| # | Outcome (by month 6) | How it is measured | Why it matters / funding case |
|---|---|---|---|
| 1 | Governance in place: council chartered, operating model approved, Owner and Steward named for 100% of 3 priority domains (Client, Portfolio & Holdings, Advisor & Assignment) | Signed council charter; Purview shows owner and steward on every priority domain | Proves the client now has accountability, the root gap in the brief; makes every later outcome sustainable |
| 2 | Enterprise glossary: 25 priority terms approved and published in Purview, including Active Client, Assets Under Management and Investment Portfolio | Count of approved terms in Purview; number of executive reports using certified definitions | Ends conflicting executive figures; leaders see one number for AUM and active clients |
| 3 | Duplicate client records reduced by 40% against the month-1 baseline | Monthly duplicate-match report across Salesforce and the Onboarding Application | Direct gain for customer experience and KYC/AML accuracy; visible cost saving in reconciliation effort |
| 4 | Critical client data completeness at target: email validity ≥ 95%, ISO country codes 100%, Tax ID ≥ 98% (where required), advisor assignment ≥ 98% (where required) | Data Quality KPI dashboard in Power BI, reported monthly to the Steering Committee | Turns quality into numbers leadership can track; supports regulatory reporting and advisor coverage |
| 5 | Purview catalogue live: all priority sources scanned and classified, end-to-end lineage from Salesforce to Power BI, and the AI pilot moved off raw Lakehouse data onto approved, governed data sources | % of priority sources scanned; lineage path visible in Purview; AI data source confirmed | Removes the largest AI-readiness blocker and gives auditors traceable lineage; unlocks Phase 2 AI investment |
Funding argument (model summary): In six months the program delivers visible accountability, one set of executive numbers, measurably cleaner client data, and a governed path for AI. Each outcome is reported on a dashboard, so the Steering Committee can see the return and fund Phase 2.
Teaching notes
- Real-world point: Phase-1-only funding is common. Governance programs that cannot show numbers early often lose their budget.
- Discussion: Why focus on three priority domains in six months? What scope would be unrealistic (for example, all domains governed, or AI in production)?
- Practice: Turn “improve data quality” into an outcome with a baseline, target and measure.
- Other valid outcomes: 20–30 Critical Data Elements identified; access review completed for external advisors; KYC documents classified with retention rules applied.
In an interview
“In the first six months we targeted a 40% cut in duplicate client records and tracked it on a Power BI dashboard for leadership.” This answers the common question “How did you measure success?”
CoachingCommon Pitfalls & Coaching Prompts
The most common slips are generic answers, invented roles and outcomes that cannot be measured. Use these prompts to steer back to the client.
| Pitfall | Where | Coaching prompt |
|---|---|---|
| Textbook definitions instead of client application | All | “Apply this to the client — which of their challenges does it solve?” |
| Standards that are not enforceable | Section 1 | “Make this testable: add a format, a threshold or a deadline.” |
| Invented job titles (e.g. Chief Data Officer) | Section 2 | “Use only titles from the org chart. Who on the chart is closest to this role?” |
| Technology role as Data Owner | Section 2 | “Technology is the custodian. Who in the business is accountable for this data?” |
| Model chosen with no trade-offs | Section 3 | “Every model has costs. What are you accepting, and why is it worth it?” |
| Missed the AI pilot reading raw Lakehouse data | Sections 1, 4, 5 | “Look at the dashed line in the data flow diagram. What risk does it create?” |
| Outcomes with no baseline or target | Section 5 | “How would the leadership team know this was achieved? Add a number.” |
| Client name or tooling codename used | All | “Refer only to ‘the client’ — real consultants protect client confidentiality.” |
InterviewInterview Practice Questions
These are questions Data Governance interviewers commonly ask, with the capstone material to draw on for each. Run them as mock interviews in pairs: one person asks, the other answers in under two minutes, using a specific example from the client.
Opening and project story
| Question | Draw on |
|---|---|
| Tell me about a data governance project you’ve worked on. | The whole engagement: client situation (four acquisitions, conflicting reports), what you built, measurable results from Section 5 |
| What was the biggest data problem you found, and how did you address it? | Duplicate client records or the AI pilot reading raw Lakehouse data; the standard or outcome that fixes it |
| How do you start a governance program in an organisation that has none? | Federated model, council, three priority domains, quick wins in six months |
Principles, policies and standards (Section 1)
| Question | Draw on |
|---|---|
| What is the difference between a principle, a policy and a standard? Give an example. | One full chain from Section 1, e.g. data quality principle → policy → ISO 8601 date standard |
| How do you make a data policy enforceable? | Testable standards with thresholds, owners and deadlines; Purview registration before report use |
| How would you handle two business units that define the same term differently? | Business glossary policy, council approval, Active Client example |
Roles and accountability (Section 2)
| Question | Draw on |
|---|---|
| Explain the difference between a Data Owner, Data Steward and Data Custodian. | Client domain example: Director Client Operations, Manager Client Onboarding, Manager CRM Systems |
| How do you decide who should be the Data Owner? | Accountability and authority to make and enforce decisions, not job title; why Directors fit this client, and when Managers or VPs can own data |
| What do you do when no one wants to take ownership of the data? | Using existing roles, executive sponsorship from VPs, showing owners the value through KPIs |
| Why shouldn’t IT own business data? | Technology as custodian; the business understands meaning and is accountable for use |
Operating model (Section 3)
| Question | Draw on |
|---|---|
| Centralised, decentralised or federated: which would you recommend and why? | Federated recommendation, justified by five business units, acquisitions and the shared Fabric/Purview platform |
| What are the downsides of the model you chose, and how do you manage them? | Slower decisions, steward time, uneven adoption; monthly council and shared KPIs |
Business case and AI (Section 4)
| Question | Draw on |
|---|---|
| How would you convince leadership to invest in data governance? | Strategic goals, cost of doing nothing, AI readiness, regulation |
| How does data governance support AI? | Approved, classified, quality-assessed, access-controlled data; lineage for explainability; moving the AI pilot off ungoverned raw data |
| Which regulations affect data governance in financial services? | Privacy (PIPEDA, Regulation S-P), AML/KYC, record-keeping; why applicability depends on the firm’s entities and jurisdictions; why governance provides the evidence regulators expect |
Value and measurement (Section 5)
| Question | Draw on |
|---|---|
| How do you measure the success of a data governance program? | The five six-month outcomes, each with baseline, target and measure |
| What quick wins would you deliver in the first 90 days? | Council chartered, owners named, first glossary terms approved, duplicate baseline measured |
| How do you keep a governance program funded after the first phase? | Monthly KPI dashboard to the Steering Committee; tying each outcome to a business priority |
Tools and hands-on (later deliverables)
| Question | Draw on |
|---|---|
| What have you done in Microsoft Purview? | Scanning sources, classifying sensitive data, building the glossary, tracing lineage from Salesforce to Power BI |
| How have you used SQL or Power BI in a governance context? | Profiling data quality issues and reporting DQ KPIs to leadership |
Coaching tip: Answer with the STAR method (Situation, Task, Action, Result) and end every answer with a number or a concrete outcome from the capstone.