Build a Data Leadership Case Study

Publish a governed analytics case study for your data leadership portfolio.

Introduction

30 Second Summary

Hiring managers can only judge the leadership evidence you can safely show them. Your strongest work often stays hidden inside company systems.

In this project, you will publish a fictional Central European retail data transformation case study in a GitHub repository entirely through your browser. The finished case study will show how you lead a data transformation from business problem to executive recommendation.

What You'll Build

When a hiring manager opens your repository, they will see a complete leadership case for transforming a fictional retailer's data operations.

By the end of this project, you'll have:

  • A public case study you can open from any browser. You can share its employer-safe link in future applications.
  • An executive snapshot with proposed business outcomes. A scored current-state assessment makes the need for change visible.
  • A governed target architecture that shows where data flows. Its data governance model assigns responsibility for trust. Its phased roadmap turns the design into an interview-ready recommendation.
  • Secret Mission: Defend the case study strategy in a focused 90-second hiring-manager response.

Are there any prerequisites?

You need a personal email address plus permission to use GitHub in a browser. The project requires no local software, Microsoft Fabric tenant, or Power BI license.

Before We Start

Before the hands-on work begins, this is your moment to define the purpose and safety boundary of an entirely fictional Northstar Retail Group case study. You are proving leadership judgment for a Prague bridge role without using real employer data, screenshots, credentials, internal metrics, or copied work products.

Set Up Your Browser-Only Portfolio

A portfolio case study only helps when a hiring manager can reach it. Your work browser is the entire workspace for this project because you cannot install local applications.

GitHub gives your case study a public home that works entirely in the browser. This step creates that home with an employer-safe starter page.

In this step, get ready to:
  • Access a verified personal GitHub account.
  • Create the public case study repository.
  • Publish the fictional scenario notice in the starter README.
Sign in to a verified GitHub account

GitHub requires a verified email address before a personal account can create repositories. Choose the path that matches your current account status.

✔️ I already have a GitHub account

  • Sign in to your personal GitHub account in the current browser.
  • Complete any email verification prompt that GitHub displays.
  • Confirm that your account gives you access to New repository.

ⓧ I need a GitHub account

  • Visit the GitHub signup page in your current browser.
  • Complete the account form with your personal email address.
  • Open the verification message that GitHub sends to your email address.
  • Follow the verification link in that message.
  • Return to GitHub in your current browser.
  • Confirm that your account gives you access to New repository.

Good, your verified account can now create the portfolio repository.

Account access still blocked?

  • Check the spam or junk folder associated with your personal email address.
  • Confirm that you followed the verification link for the same account currently open in your browser.
  • Sign out if the browser opened a work account instead of your personal account.
  • Still stuck? Help me access and verify my personal GitHub account.
Create the public repository

A repository stores the case study page that hiring managers will open. Turning on a README gives the repository an immediate front page.

A public repository makes its contents visible to anyone. Your starter content stays safe because it contains only the fictional Northstar scenario notice.

  • Select New repository from GitHub's repository creation menu.
  • Enter prague-data-leadership-case-study in the repository name field.
  • Set the repository visibility to public.
  • Turn on Add README.
  • Select Create repository.

You should see prague-data-leadership-case-study at the top of the page. A README section should appear below the repository files.

Repository creation not available?

  • Confirm that your personal email address has completed GitHub verification.
  • Check that prague-data-leadership-case-study is entered as the repository name.
  • Return to your personal account if the browser switched to a work-managed GitHub account.
  • Still stuck? Help me create my public GitHub repository.
Publish the starter README

The first page establishes the case study's title before any strategy content appears. Its notice also makes the fictional boundary visible from the start.

  • Select README.md from the repository file list.
  • Choose the file-editing control in the upper-right area of the file view.
  • Select all existing text in the editor.
  • Replace the selected text by pasting this exact starter README:
# Data Leadership Case Study: Northstar Retail Group

> Fictional portfolio scenario created for professional development. It contains no employer data, code, screenshots, or confidential information.

What does this Markdown do?

  • The leading # makes the project title a top-level Markdown heading.
  • The leading > formats the fictional-scenario notice as a blockquote.
  • The notice sets a clear boundary against publishing employer information.
  • Select Preview above the editor.

You should see the project title rendered as a large heading. The fictional-scenario notice should appear beneath it as a blockquote.

The commit control opens a confirmation dialog before GitHub saves your edit.

  • Select Commit changes....
  • Select Commit changes in the confirmation dialog.

Before you check, consider whether GitHub will show source symbols or a formatted heading.

  • Return to the repository front page by selecting prague-data-leadership-case-study in the repository breadcrumb.
  • Refresh the repository front page in your browser.

You should see the heading Data Leadership Case Study: Northstar Retail Group in the README area. The fictional-scenario notice should appear directly below it.

README changes not showing?

  • Confirm that you selected all of the original README text before pasting the new content.
  • Check that Preview shows both the heading and the fictional-scenario notice.
  • Confirm that you completed both commit controls in the confirmation flow.
  • Still stuck? Help me publish the starter README through GitHub's browser editor.

✔️ Awesome, I've got everything!

Your committed README now matches the employer-safe starter page for this case study.

ⓧ I'd like to double check the full code

# Data Leadership Case Study: Northstar Retail Group

> Fictional portfolio scenario created for professional development. It contains no employer data, code, screenshots, or confidential information.

What should match?

Compare both lines with your committed README.md. The blank line between them keeps the heading separate from the fictional-scenario notice.

Your browser-only portfolio is live with a clear fictional boundary. Next, you will expand it with the executive summary and business evidence that make your leadership judgment visible.

Publish the Executive Snapshot

Your starter README gives the fictional case study a safe public home. Its opening now needs to show the leadership judgment behind the proposed transformation.

A portfolio entry that opens with tools can hide the decisions you are ready to make. This step leads with the business problem before presenting measurable outcomes or maturity gaps.

In this step, get ready to:
  • Write a business-first executive summary for the fictional retailer.
  • Connect each proposed outcome to evidence of progress.
  • Present the current-state assessment as a fictional scenario.
Frame the decision problem

The GitHub browser editor lets you expand the case study without installing local software. The executive summary frames fragmented reporting as a business problem before architecture enters the story.

  • Select README.md from the repository file list.
  • Use the edit control in the file toolbar to enter editing mode.
  • Place your cursor after the fictional-scenario notice.
  • Add the executive summary by copying the Markdown below:
## Executive Summary

Northstar Retail Group is a fictional Central European retailer whose Finance, Sales, and Supply Chain teams maintain separate reports, KPI definitions, and spreadsheet reconciliations. Leaders receive conflicting answers to basic performance questions, while analysts spend time reconciling numbers instead of improving decisions.

The proposal is to establish governed, reusable data products on a unified analytics platform. Business domains remain accountable for meaning and quality, while a central platform team supplies shared architecture, security, and delivery standards.

What does this section do?

  • The retailer description frames conflicting reports as a leadership decision problem.
  • The proposal introduces governed, reusable data products as the response.
  • Business domains keep accountability for meaning and quality.
  • The central platform team supplies shared standards.
  • Select Preview in the editor.
  • Confirm that the Executive Summary heading appears beneath the fictional-scenario notice.
  • Confirm that two paragraphs appear beneath the heading.

Your case study now opens with the reporting problem that the platform proposal needs to solve.

Executive Summary Missing From the Preview?

  • Check that ## Executive Summary starts on its own line.
  • Check that a blank line separates the heading from the first paragraph.
  • Still stuck? Help me inspect the executive summary formatting.
Build the evidence tables

Business outcomes connect intended change to evidence of progress. A maturity assessment makes the starting gaps visible across the fictional organization.

  • Select the tab beside Preview to return to the editing view.
  • Place your cursor after the final executive-summary paragraph.
  • Add the Business Outcomes section by copying the code below:
## Business Outcomes

| Outcome | Proposed target | Evidence of progress |
| --- | --- | --- |
| Faster decisions | Executive reporting available by the next business day | Reporting-cycle lead time |
| Trusted metrics | One approved owner and definition for every Tier-1 KPI | Percentage of Tier-1 KPIs with an owner and definition |
| Visible quality | Material issues assigned a severity, owner, and resolution target | Open issues by severity and age |
| Reusable analytics | Certified shared data products become the default reporting source | Adoption of governed data products |

These are proposed targets for the fictional scenario, not claims about a real company.

What does this table show?

  • Each outcome describes a business change that leadership can recognize.
  • Each proposed target gives that change a practical direction.
  • The final column identifies evidence that could show progress.
  • The sentence beneath the table keeps every target inside the fictional scenario.
  • Select Preview in the editor.
  • Confirm that the Business Outcomes table displays three column headers.
  • Confirm that four outcome rows appear beneath the headers.
  • Confirm that the fictional-scenario sentence appears directly beneath the table.

The proposed outcomes now read as measurable leadership priorities without presenting fictional targets as employer results.

Business Outcomes Table Showing as Plain Text?

  • Check that every table row starts with a vertical bar.
  • Check that every table row ends with a vertical bar.
  • Check that the separator row sits directly beneath the header row.
  • Still stuck? Help me troubleshoot the Business Outcomes table.
  • Select the tab beside Preview to return to the editing view.
  • Place your cursor after the fictional-scenario sentence.
  • Add the Current-State Assessment section by copying the code below:
## Current-State Assessment

| Capability | Score | Observation |
| --- | ---: | --- |
| Business alignment | 2/5 | Reporting demand is handled project by project rather than through a shared portfolio. |
| Data ownership | 1/5 | Technical teams are expected to resolve disagreements about business meaning. |
| Architecture | 2/5 | Multiple reporting pipelines duplicate transformations and controls. |
| Data quality | 1/5 | Issues are corrected manually without common severity or ownership rules. |
| Self-service | 2/5 | Users can build reports, but trusted reusable sources are difficult to identify. |

What does this assessment reveal?

  • The capability column separates five areas that influence trustworthy analytics.
  • The scenario scores make the maturity gaps visible at a glance.
  • The observations explain the business consequences behind those scores.
  • The low ownership score prepares the case study for a later governance response.
  • Select Preview in the editor.
  • Confirm that the Current-State Assessment table displays five capability rows.
  • Confirm that every capability has a score.
  • Confirm that every score has a written observation.

The snapshot now connects the reporting problem to proposed outcomes and visible maturity gaps.

Current-State Assessment Table Showing as Plain Text?

  • Check that the score separator contains ---: beneath the Score header.
  • Check that each capability stays on one table row.
  • Still stuck? Help me troubleshoot the Current-State Assessment table.

✔️ Awesome, I've got everything!

Great. Double-check that your edited README.md contains the executive summary plus both evidence tables.

ⓧ I'd like to double check the full code

# Data Leadership Case Study: Northstar Retail Group

> Fictional portfolio scenario created for professional development. It contains no employer data, code, screenshots, or confidential information.

## Executive Summary

Northstar Retail Group is a fictional Central European retailer whose Finance, Sales, and Supply Chain teams maintain separate reports, KPI definitions, and spreadsheet reconciliations. Leaders receive conflicting answers to basic performance questions, while analysts spend time reconciling numbers instead of improving decisions.

The proposal is to establish governed, reusable data products on a unified analytics platform. Business domains remain accountable for meaning and quality, while a central platform team supplies shared architecture, security, and delivery standards.

## Business Outcomes

| Outcome | Proposed target | Evidence of progress |
| --- | --- | --- |
| Faster decisions | Executive reporting available by the next business day | Reporting-cycle lead time |
| Trusted metrics | One approved owner and definition for every Tier-1 KPI | Percentage of Tier-1 KPIs with an owner and definition |
| Visible quality | Material issues assigned a severity, owner, and resolution target | Open issues by severity and age |
| Reusable analytics | Certified shared data products become the default reporting source | Adoption of governed data products |

These are proposed targets for the fictional scenario, not claims about a real company.

## Current-State Assessment

| Capability | Score | Observation |
| --- | ---: | --- |
| Business alignment | 2/5 | Reporting demand is handled project by project rather than through a shared portfolio. |
| Data ownership | 1/5 | Technical teams are expected to resolve disagreements about business meaning. |
| Architecture | 2/5 | Multiple reporting pipelines duplicate transformations and controls. |
| Data quality | 1/5 | Issues are corrected manually without common severity or ownership rules. |
| Self-service | 2/5 | Users can build reports, but trusted reusable sources are difficult to identify. |
Publish the executive snapshot

The finished snapshot should make sense before a hiring manager reaches any technology. A final review protects the fictional framing before the page becomes public.

  • Read the preview from the project title through the Current-State Assessment table.
  • Confirm that the reporting problem appears before the proposed platform response.
  • Confirm that Northstar Retail Group is described as fictional.
  • Confirm that the proposed targets are labelled as part of the fictional scenario.
  • Confirm that the fictional-scenario notice remains above the assessment scores.

The commit control opens a dialog where you provide a short message for this update.

  • Select Commit changes... in the editor toolbar.
  • Enter Publish executive snapshot in the commit message field.
  • Select Commit changes in the commit dialog.

Before you refresh, which three new section headings do you expect to see beneath the fictional-scenario notice?

  • Return to the repository front page.
  • Refresh the page in your browser.
  • Confirm that the Executive Summary heading appears with two paragraphs.
  • Confirm that the Business Outcomes table appears with four outcome rows.
  • Confirm that the Current-State Assessment table appears with five capability rows.

That is a strong first impression. Your public case study now leads with business judgment before technology.

Committed but Still Seeing the Starter README?

  • Refresh the repository front page after the commit completes.
  • Select README.md from the file list to inspect its latest committed contents.
  • Check that you edited the README.md file inside prague-data-leadership-case-study.
  • Still stuck? Help me find my committed README changes.

Your executive snapshot now establishes the business case. Next, you will turn that case into a target data platform diagram.

Map the Target Data Platform

The executive snapshot now gives Northstar's fictional reporting problem a business frame. The next layer needs to show how data travels from scattered sources to decisions.

A platform diagram rendered by GitHub proves technical range to a hiring manager. Its leadership value depends on whether the finished picture answers the executive questions that matter.

In this step, get ready to:
  • Add a rendered architecture diagram to the case study.
  • Explain the purpose of each platform layer.
  • Commit the architecture as a coherent portfolio checkpoint.
Add the technology flow

Mermaid turns plain text into a diagram that GitHub can render inside a Markdown file. A left-to-right flow lets a reader trace the journey from operational sources to business reports.

  • From the repository front page, select README.md in the file list.
  • Use the file's edit control above the file to return to the browser editor.
  • Find the final row of the Current-State Assessment table.
  • Place your cursor on a new line below that table.
  • Add the technology flow by pasting this section:
## Target Architecture

```mermaid
flowchart LR
    A["ERP, CRM, and spreadsheets"] --> B["Microsoft Fabric data platform"]
    B --> C["OneLake governed data products"]
    C --> D["Power BI semantic models"]
    D --> E["Executive and self-service reports"]
```

What does this diagram do?

  • The declaration flowchart LR lays out the diagram from left to right.
  • Each --> creates a directional connection between two stages.
  • Microsoft Fabric acts as the shared analytics platform boundary.
  • OneLake represents the governed data products used across the company.
  • Power BI semantic models turn those products into reporting-ready structures.

Before you select Preview, do you think a clean data flow can answer every leadership question?

  • Select Preview above the editor.

You'll see a left-to-right path from source systems to reports. Each stage appears as a labelled box.

  • Scan every node for the person or role responsible for the data.

No domain owner appears. No data steward appears.

No governance control appears either. That shortfall is intentional.

The diagram explains where data travels. It leaves definitions, quality, access, and trust without visible ownership.

Diagram not rendering?

  • Check that the opening fence uses mermaid in lowercase.
  • Confirm that the first diagram line is exactly flowchart LR.
  • Check that every connection uses --> between two node identifiers.
  • Still stuck? Help me fix a Mermaid flowchart that is not rendering in my GitHub README.
Explain the architecture intent

The diagram shows the sequence of the proposed platform. Architecture intent gives each layer a business-facing purpose that a reader can understand without extra context.

  • Return to the editing view below the preview.
  • Place your cursor on a new line below the diagram's closing fence.
  • Add the architecture intent by pasting this content:
Architecture intent:

- Microsoft Fabric provides the shared analytics platform boundary for the proposal.
- OneLake provides unified storage for governed analytics data.
- Power BI semantic models provide reporting-ready models and consistent calculations.

Why add architecture intent?

The three bullets make the architecture legible without requiring platform knowledge. They connect each layer to its role in the proposal.

  • Select Preview above the editor.

You should see an Architecture intent label beneath the rendered diagram. Three bullets should explain the roles of Microsoft Fabric, OneLake, and Power BI semantic models.

Architecture intent missing?

  • Check that Architecture intent: appears below the diagram's closing fence.
  • Confirm that each explanation begins with a Markdown hyphen.
  • Still stuck? Help me fix the architecture intent section in my README.

✔️ Awesome, I've got everything!

Your README.md should now match this checkpoint.

ⓧ I'd like to double check the full code

The complete file for this checkpoint is shown below.

# Data Leadership Case Study: Northstar Retail Group

> Fictional portfolio scenario created for professional development. It contains no employer data, code, screenshots, or confidential information.

## Executive Summary

Northstar Retail Group is a fictional Central European retailer whose Finance, Sales, and Supply Chain teams maintain separate reports, KPI definitions, and spreadsheet reconciliations. Leaders receive conflicting answers to basic performance questions, while analysts spend time reconciling numbers instead of improving decisions.

The proposal is to establish governed, reusable data products on a unified analytics platform. Business domains remain accountable for meaning and quality, while a central platform team supplies shared architecture, security, and delivery standards.

## Business Outcomes

| Outcome | Proposed target | Evidence of progress |
| --- | --- | --- |
| Faster decisions | Executive reporting available by the next business day | Reporting-cycle lead time |
| Trusted metrics | One approved owner and definition for every Tier-1 KPI | Percentage of Tier-1 KPIs with an owner and definition |
| Visible quality | Material issues assigned a severity, owner, and resolution target | Open issues by severity and age |
| Reusable analytics | Certified shared data products become the default reporting source | Adoption of governed data products |

These are proposed targets for the fictional scenario, not claims about a real company.

## Current-State Assessment

| Capability | Score | Observation |
| --- | ---: | --- |
| Business alignment | 2/5 | Reporting demand is handled project by project rather than through a shared portfolio. |
| Data ownership | 1/5 | Technical teams are expected to resolve disagreements about business meaning. |
| Architecture | 2/5 | Multiple reporting pipelines duplicate transformations and controls. |
| Data quality | 1/5 | Issues are corrected manually without common severity or ownership rules. |
| Self-service | 2/5 | Users can build reports, but trusted reusable sources are difficult to identify. |

## Target Architecture

```mermaid
flowchart LR
    A["ERP, CRM, and spreadsheets"] --> B["Microsoft Fabric data platform"]
    B --> C["OneLake governed data products"]
    C --> D["Power BI semantic models"]
    D --> E["Executive and self-service reports"]
```

Architecture intent:

- Microsoft Fabric provides the shared analytics platform boundary for the proposal.
- OneLake provides unified storage for governed analytics data.
- Power BI semantic models provide reporting-ready models and consistent calculations.
Commit and verify the technology-only architecture

The preview proves that the Markdown is valid. Committing it turns the diagram into the public checkpoint that a hiring manager sees.

  • Return to the editing view.
  • Select Commit changes...
  • Select Commit changes in the confirmation dialog.

Before you refresh, do you think the committed page tells a complete leadership story?

  • Refresh the repository front page.

You'll see Target Architecture above a rendered left-to-right flow. The path begins with ERP, CRM, and spreadsheets.

The flow continues through Microsoft Fabric, OneLake, and Power BI semantic models. It ends with executive and self-service reports.

No domain-owner, data-steward, or governance-control node appears. That visible omission is the checkpoint for this step.

You have the technical story on the page now. Any hiring manager can trace the proposed path from source systems to reports.

Committed page not showing the diagram?

  • Confirm that the committed README.md contains both fences around the Mermaid block.
  • Refresh the browser after the commit finishes.
  • Still stuck? Help me diagnose why my committed Mermaid diagram is missing from GitHub.

The data path is visible, while its ownership gap remains exposed. Next, you'll add the governance roles and decision rights that make the architecture accountable.

Add the Governance Operating Model

Your rendered GitHub case study now shows data moving from source systems into reports. The missing owner leaves accountability unresolved.

Data governance ties business decisions to named roles. This step adds that accountability to the architecture.

Your operating model will connect named roles to governed data products. A decision-rights matrix will show who makes each decision.

In this step, get ready to:
  • Connect governance responsibilities to the architecture.
  • Assign accountable ownership for each business domain.
  • Publish a decision-rights matrix for the case study.
Connect governance to the architecture

The Mermaid diagram already traces the technical flow. Governance becomes visible when the architecture identifies the people attached to the governed data products.

  • Select README.md on the repository front page.
  • Select the pencil icon above the README to use the browser editor.
  • Find the section beginning with ## Target Architecture.
  • Replace the entire Target Architecture section with the governed version below:
## Target Architecture

```mermaid
flowchart LR
    A["ERP, CRM, and spreadsheets"] --> B["Microsoft Fabric data platform"]
    B --> C["OneLake governed data products"]
    C --> D["Power BI semantic models"]
    D --> E["Executive and self-service reports"]
    F["Domain owners"] --> C
    G["Data stewards"] --> C
    H["Quality, access, lineage, and endorsement controls"] --> C
```

Architecture intent:

- Microsoft Fabric provides the shared analytics platform boundary for the proposal.
- OneLake provides unified storage for governed analytics data.
- Power BI semantic models provide reporting-ready models and consistent calculations.
- Domain owners remain accountable for definitions, quality expectations, and sharing decisions.
- Data stewards operate metadata, quality, and issue-management practices.

What changed in the architecture?

  • The F["Domain owners"] --> C connection assigns business accountability to the governed data products.
  • The G["Data stewards"] --> C connection identifies who operates the governance practices.
  • The H["Quality, access, lineage, and endorsement controls"] --> C connection shows how trust is maintained.
  • All three connections point to OneLake governed data products because that is where ownership meets the technical flow.
  • Select Preview above the editor.
  • Inspect the rendered diagram for three new arrows entering the OneLake governed data products node.

You should see Domain owners, Data stewards, and Quality, access, lineage, and endorsement controls on the left side of the governed data products.

Good progress. Your architecture now shows who owns trust in the data instead of presenting technology as the whole solution.

Diagram not rendering?

  • Check that the opening fence is ```mermaid.
  • Check that each governance connection ends with --> C.
  • Compare the quotation marks around each node label with the code above.
  • Still stuck? Help me find why my governed Mermaid diagram is not rendering in GitHub.
Assign ownership by business domain

The architecture names general roles. The operating model makes those roles concrete for Sales, Finance, and Supply Chain.

  • Select the editing tab beside Preview.
  • Find the final architecture-intent bullet ending with issue-management practices..
  • Place your cursor on a new line below that bullet.
  • Add the Governance Operating Model section by pasting the following content:
## Governance Operating Model

| Domain | Accountable owner | Responsible steward | Governed data product | Tier-1 KPI example |
| --- | --- | --- | --- | --- |
| Sales | Commercial Director | Sales Data Steward | Customer and sales performance | Net sales |
| Finance | Finance Director | Finance Data Steward | Financial actuals | Operating margin |
| Supply Chain | Operations Director | Supply Chain Data Steward | Inventory and fulfilment | On-time fulfilment |

How does the operating model work?

  • The Accountable owner holds final business accountability for the domain.
  • The Responsible steward maintains the domain's governance practices.
  • The Governed data product names the reusable information asset supported by those roles.
  • The Tier-1 KPI example connects each domain to a decision-critical measure.
  • Select Preview above the editor.
  • Inspect the Governance Operating Model table for three business-domain rows.

You should see separate rows for Sales, Finance, and Supply Chain. Each row should name one owner, one steward, one governed data product, and one Tier-1 KPI example.

Table columns not lining up?

  • Check that every table row starts with a vertical bar.
  • Check that every table row ends with a vertical bar.
  • Confirm that the separator row contains five cells.
  • Still stuck? Help me fix the Markdown structure of my Governance Operating Model table.
Define decision rights and publish the update

A RACI matrix separates final accountability from delivery work. This keeps platform decisions from becoming ownerless technical tasks.

  • Select the editing tab beside Preview.
  • Place your cursor on a new line below the Supply Chain row.
  • Add the Decision Rights section by pasting the following content:
### Decision Rights

| Decision | Executive sponsor | Domain owner | Data steward | Platform lead | BI team |
| --- | --- | --- | --- | --- | --- |
| Approve Tier-1 KPI definition | I | A | R | C | C |
| Set data-quality expectation | I | A | R | C | C |
| Resolve a material quality issue | I | A | R | C | R |
| Approve platform architecture standard | C | C | C | A/R | I |
| Grant access to a governed data product | I | A | R | C | I |
| Release an executive report | I | A | C | C | R |

Legend: A = Accountable, R = Responsible, C = Consulted, I = Informed.

How do the decision rights work?

  • The A identifies the role with final accountability for a decision.
  • The R identifies the role that performs the work.
  • The C identifies a role whose input shapes the decision.
  • The I identifies a role that receives the outcome.
  • The A/R assignment gives the platform lead both accountability and responsibility for architecture standards.

Before you preview the finished update, do you expect most business decisions to belong to domain owners or the platform lead?

  • Select Preview above the editor.
  • Inspect the architecture followed by both governance tables.

You should see three governance arrows entering the OneLake governed data products node. Beneath the architecture, you should see the Governance Operating Model and Decision Rights tables.

The matrix places most business accountability with domain owners. The platform lead owns the architecture standard.

  • Select Commit changes... in the upper-right corner.
  • Enter Add governance operating model in the commit message field.
  • Select Commit changes in the dialog.

You should see the repository front page with the governed architecture followed by both governance tables. That is the ownership gap closed: your case study now connects technical design to accountable leadership.

Governance update missing after the commit?

  • Refresh the repository front page if the previous README version is still visible.
  • Check that the Governance Operating Model heading sits outside the closing Mermaid fence.
  • Compare the rendered table rows with the complete file below if a role appears under the wrong column.
  • Still stuck? Help me troubleshoot why my committed GitHub README does not show the governed architecture and decision-rights tables correctly.

✔️ Awesome, I've got everything!

Your committed README.md now matches the complete governance update.

ⓧ I'd like to double check the full code

# Data Leadership Case Study: Northstar Retail Group

> Fictional portfolio scenario created for professional development. It contains no employer data, code, screenshots, or confidential information.

## Executive Summary

Northstar Retail Group is a fictional Central European retailer whose Finance, Sales, and Supply Chain teams maintain separate reports, KPI definitions, and spreadsheet reconciliations. Leaders receive conflicting answers to basic performance questions, while analysts spend time reconciling numbers instead of improving decisions.

The proposal is to establish governed, reusable data products on a unified analytics platform. Business domains remain accountable for meaning and quality, while a central platform team supplies shared architecture, security, and delivery standards.

## Business Outcomes

| Outcome | Proposed target | Evidence of progress |
| --- | --- | --- |
| Faster decisions | Executive reporting available by the next business day | Reporting-cycle lead time |
| Trusted metrics | One approved owner and definition for every Tier-1 KPI | Percentage of Tier-1 KPIs with an owner and definition |
| Visible quality | Material issues assigned a severity, owner, and resolution target | Open issues by severity and age |
| Reusable analytics | Certified shared data products become the default reporting source | Adoption of governed data products |

These are proposed targets for the fictional scenario, not claims about a real company.

## Current-State Assessment

| Capability | Score | Observation |
| --- | ---: | --- |
| Business alignment | 2/5 | Reporting demand is handled project by project rather than through a shared portfolio. |
| Data ownership | 1/5 | Technical teams are expected to resolve disagreements about business meaning. |
| Architecture | 2/5 | Multiple reporting pipelines duplicate transformations and controls. |
| Data quality | 1/5 | Issues are corrected manually without common severity or ownership rules. |
| Self-service | 2/5 | Users can build reports, but trusted reusable sources are difficult to identify. |

## Target Architecture

```mermaid
flowchart LR
    A["ERP, CRM, and spreadsheets"] --> B["Microsoft Fabric data platform"]
    B --> C["OneLake governed data products"]
    C --> D["Power BI semantic models"]
    D --> E["Executive and self-service reports"]
    F["Domain owners"] --> C
    G["Data stewards"] --> C
    H["Quality, access, lineage, and endorsement controls"] --> C
```

Architecture intent:

- Microsoft Fabric provides the shared analytics platform boundary for the proposal.
- OneLake provides unified storage for governed analytics data.
- Power BI semantic models provide reporting-ready models and consistent calculations.
- Domain owners remain accountable for definitions, quality expectations, and sharing decisions.
- Data stewards operate metadata, quality, and issue-management practices.

## Governance Operating Model

| Domain | Accountable owner | Responsible steward | Governed data product | Tier-1 KPI example |
| --- | --- | --- | --- | --- |
| Sales | Commercial Director | Sales Data Steward | Customer and sales performance | Net sales |
| Finance | Finance Director | Finance Data Steward | Financial actuals | Operating margin |
| Supply Chain | Operations Director | Supply Chain Data Steward | Inventory and fulfilment | On-time fulfilment |

### Decision Rights

| Decision | Executive sponsor | Domain owner | Data steward | Platform lead | BI team |
| --- | --- | --- | --- | --- | --- |
| Approve Tier-1 KPI definition | I | A | R | C | C |
| Set data-quality expectation | I | A | R | C | C |
| Resolve a material quality issue | I | A | R | C | R |
| Approve platform architecture standard | C | C | C | A/R | I |
| Grant access to a governed data product | I | A | R | C | I |
| Release an executive report | I | A | C | C | R |

Legend: A = Accountable, R = Responsible, C = Consulted, I = Informed.

Your case study now proves that architecture needs accountable people as well as technology. Next, you will turn this governed design into a phased roadmap and an interview-ready executive story.

Finish the Leadership Roadmap and Interview Story

Your GitHub case study now connects a governed architecture to clear ownership. The remaining gap is execution.

Architecture without sequencing does not prove that you can lead change. Technical judgment also loses impact when you cannot explain it to an executive audience.

A phased roadmap makes the proposal executable. Risk responses show leadership accountability. A concise interview story makes the whole strategy easier to defend.

In this step, get ready to:
  • Sequence the transformation through four delivery phases.
  • Connect strategic risks to leadership mitigations.
  • Complete the executive interview story.
Turn strategy into delivery phases

A roadmap turns the target operating model into a sequence of decisions. Each phase should prove enough value to justify the next investment.

  • Select the edit control above README.md to enter the editing view.
  • Paste the roadmap block below at the end of README.md:
## Delivery Roadmap

### First 30 Days: Align and Inventory

- Confirm the executive sponsor and the three domain owners.
- Inventory Tier-1 decisions, KPIs, reports, sources, and recurring quality issues.
- Select one high-value data product using business urgency, reuse potential, and delivery risk.

### Days 31 to 60: Prove the Operating Model

- Define the pilot data product, its owner, steward, consumers, quality expectations, and access rules.
- Design the reporting-ready semantic model and agree the first certified KPI definitions.
- Establish a visible issue register and weekly owner-led quality review.

### Days 61 to 90: Publish and Drive Adoption

- Publish the pilot as the approved source for its selected decision process.
- Retire or label conflicting reports and document the migration path for consumers.
- Review adoption, reporting lead time, quality trends, and unresolved ownership decisions with leadership.

### Months 3 to 12: Scale Deliberately

- Extend the operating model to additional domains only after the pilot proves ownership and value.
- Introduce shared lifecycle, cost, security, lineage, endorsement, and release standards.
- Review the data-product portfolio regularly and pause products whose value or ownership has weakened.

How does the roadmap build confidence?

  • The first 30 days establish sponsorship. They also establish ownership.
  • The next 60 days prove one governed data product through delivery.
  • The final phase makes wider expansion conditional on demonstrated value.
  • Select Preview above the editor.

You'll see a Delivery Roadmap with four distinct time periods. Each period has three leadership actions.

Roadmap headings not rendering?

  • Confirm the main heading begins with ##.
  • Confirm each delivery phase begins with ###.
  • Compare the blank lines around each heading with the reference block.
  • Still stuck? Help me fix the roadmap formatting in my README.
Turn risks into leadership actions

A credible strategy acknowledges what could derail delivery. A leadership mitigation assigns a decision or behavior that reduces each risk.

  • Return to the editing view for README.md.
  • Paste the risk block below at the end of README.md:
## Key Risks and Mitigations

| Risk | Leadership mitigation |
| --- | --- |
| Technology work starts before ownership is agreed | Require an accountable domain owner before funding a data product. |
| The program recreates every existing report | Prioritize decision-critical data products and retire duplication deliberately. |
| Governance becomes a central approval bottleneck | Delegate decisions to domains within a small set of enterprise guardrails. |
| Quality remains an IT problem | Make domain owners accountable and stewards responsible for visible issue resolution. |
| Adoption is assumed rather than measured | Track governed-product usage, reporting lead time, and retirement of conflicting outputs. |

What makes these mitigations credible?

  • Each mitigation names a leadership action.
  • Ownership becomes a condition for investment.
  • Adoption becomes measurable evidence.
  • Enterprise guardrails preserve domain decision-making.
  • Select Preview above the editor.

You'll see a two-column table with five strategic risks. Every row pairs the risk with a concrete leadership response.

Risk table not displaying correctly?

  • Confirm every table row begins with a vertical bar.
  • Confirm the header separator remains directly below the table headings.
  • Still stuck? Help me repair the risk table in my README.
Finish the interview story

The final sections compress the case study into an interview-ready recommendation. They also make the fictional boundaries explicit.

  • Return to the editing view for README.md.
  • Paste the interview pitch and ethical-use block below at the end of README.md:
## Executive Interview Pitch

Northstar does not primarily have a dashboard problem. It has an accountability and decision-confidence problem. I would begin by agreeing the decisions and Tier-1 KPIs that matter, then assign domain owners who can approve definitions, quality expectations, and access. The target architecture uses Microsoft Fabric, OneLake, and Power BI to create reusable reporting-ready data products, but the platform is only an enabler. In the first 30 days I would inventory decisions, reports, sources, and quality issues, then select one product with visible business value. By day 90, leadership should have an approved source, clear ownership, measurable adoption, and a repeatable governance pattern. That creates evidence for scaling while avoiding a technology-first transformation.

## Assumptions and Ethical Use

- Northstar Retail Group is fictional.
- All maturity scores, targets, roles, and risks are scenario assumptions.
- The architecture is a proposal, not evidence of a deployed Microsoft Fabric environment.
- No confidential employer material should be added to this repository.

How does this strengthen the case study?

  • The pitch moves from the decision problem to the first delivery phase.
  • The recommendation connects platform choices to ownership.
  • The assumptions section protects employer confidentiality.
  • The ethical-use statement keeps every claim accurate.
  • Select Preview above the editor.

You'll see the Executive Interview Pitch below the risk table. The Assumptions and Ethical Use section follows the pitch.

Pitch or assumptions missing?

  • Confirm both section headings begin with ##.
  • Confirm the four ethical-use statements each begin on a separate line.
  • Still stuck? Help me find the missing final sections in my README.
  • Return to the editing view for README.md.
  • Paste the proof-point block below at the end of README.md:
## What This Demonstrates

- Business-first data strategy
- Analytics and semantic architecture
- Domain ownership and data-product thinking
- Data governance and decision rights
- Phased transformation planning
- Executive communication and risk awareness

What do these proof points show?

The six proof points translate the artifact into leadership capabilities. A hiring manager can scan them before exploring the detailed evidence above.

  • Select Preview above the editor.

You'll see six proof points under What This Demonstrates. The final point highlights executive communication with risk awareness.

Proof points not appearing as bullets?

  • Confirm each proof point begins on a new line.
  • Confirm each line begins with a hyphen followed by a space.
  • Still stuck? Help me fix the What This Demonstrates list.

Use the tabs below to compare your finished README.md with the complete case study.

✔️ Awesome, I've got everything!

Great. Keep the complete preview open for the final publishing check.

ⓧ I'd like to double check the full code

# Data Leadership Case Study: Northstar Retail Group

> Fictional portfolio scenario created for professional development. It contains no employer data, code, screenshots, or confidential information.

## Executive Summary

Northstar Retail Group is a fictional Central European retailer whose Finance, Sales, and Supply Chain teams maintain separate reports, KPI definitions, and spreadsheet reconciliations. Leaders receive conflicting answers to basic performance questions, while analysts spend time reconciling numbers instead of improving decisions.

The proposal is to establish governed, reusable data products on a unified analytics platform. Business domains remain accountable for meaning and quality, while a central platform team supplies shared architecture, security, and delivery standards.

## Business Outcomes

| Outcome | Proposed target | Evidence of progress |
| --- | --- | --- |
| Faster decisions | Executive reporting available by the next business day | Reporting-cycle lead time |
| Trusted metrics | One approved owner and definition for every Tier-1 KPI | Percentage of Tier-1 KPIs with an owner and definition |
| Visible quality | Material issues assigned a severity, owner, and resolution target | Open issues by severity and age |
| Reusable analytics | Certified shared data products become the default reporting source | Adoption of governed data products |

These are proposed targets for the fictional scenario, not claims about a real company.

## Current-State Assessment

| Capability | Score | Observation |
| --- | ---: | --- |
| Business alignment | 2/5 | Reporting demand is handled project by project rather than through a shared portfolio. |
| Data ownership | 1/5 | Technical teams are expected to resolve disagreements about business meaning. |
| Architecture | 2/5 | Multiple reporting pipelines duplicate transformations and controls. |
| Data quality | 1/5 | Issues are corrected manually without common severity or ownership rules. |
| Self-service | 2/5 | Users can build reports, but trusted reusable sources are difficult to identify. |

## Target Architecture

```mermaid
flowchart LR
    A["ERP, CRM, and spreadsheets"] --> B["Microsoft Fabric data platform"]
    B --> C["OneLake governed data products"]
    C --> D["Power BI semantic models"]
    D --> E["Executive and self-service reports"]
    F["Domain owners"] --> C
    G["Data stewards"] --> C
    H["Quality, access, lineage, and endorsement controls"] --> C
```

Architecture intent:

- Microsoft Fabric provides the shared analytics platform boundary for the proposal.
- OneLake provides unified storage for governed analytics data.
- Power BI semantic models provide reporting-ready models and consistent calculations.
- Domain owners remain accountable for definitions, quality expectations, and sharing decisions.
- Data stewards operate metadata, quality, and issue-management practices.

## Governance Operating Model

| Domain | Accountable owner | Responsible steward | Governed data product | Tier-1 KPI example |
| --- | --- | --- | --- | --- |
| Sales | Commercial Director | Sales Data Steward | Customer and sales performance | Net sales |
| Finance | Finance Director | Finance Data Steward | Financial actuals | Operating margin |
| Supply Chain | Operations Director | Supply Chain Data Steward | Inventory and fulfilment | On-time fulfilment |

### Decision Rights

| Decision | Executive sponsor | Domain owner | Data steward | Platform lead | BI team |
| --- | --- | --- | --- | --- | --- |
| Approve Tier-1 KPI definition | I | A | R | C | C |
| Set data-quality expectation | I | A | R | C | C |
| Resolve a material quality issue | I | A | R | C | R |
| Approve platform architecture standard | C | C | C | A/R | I |
| Grant access to a governed data product | I | A | R | C | I |
| Release an executive report | I | A | C | C | R |

Legend: A = Accountable, R = Responsible, C = Consulted, I = Informed.

## Delivery Roadmap

### First 30 Days: Align and Inventory

- Confirm the executive sponsor and the three domain owners.
- Inventory Tier-1 decisions, KPIs, reports, sources, and recurring quality issues.
- Select one high-value data product using business urgency, reuse potential, and delivery risk.

### Days 31 to 60: Prove the Operating Model

- Define the pilot data product, its owner, steward, consumers, quality expectations, and access rules.
- Design the reporting-ready semantic model and agree the first certified KPI definitions.
- Establish a visible issue register and weekly owner-led quality review.

### Days 61 to 90: Publish and Drive Adoption

- Publish the pilot as the approved source for its selected decision process.
- Retire or label conflicting reports and document the migration path for consumers.
- Review adoption, reporting lead time, quality trends, and unresolved ownership decisions with leadership.

### Months 3 to 12: Scale Deliberately

- Extend the operating model to additional domains only after the pilot proves ownership and value.
- Introduce shared lifecycle, cost, security, lineage, endorsement, and release standards.
- Review the data-product portfolio regularly and pause products whose value or ownership has weakened.

## Key Risks and Mitigations

| Risk | Leadership mitigation |
| --- | --- |
| Technology work starts before ownership is agreed | Require an accountable domain owner before funding a data product. |
| The program recreates every existing report | Prioritize decision-critical data products and retire duplication deliberately. |
| Governance becomes a central approval bottleneck | Delegate decisions to domains within a small set of enterprise guardrails. |
| Quality remains an IT problem | Make domain owners accountable and stewards responsible for visible issue resolution. |
| Adoption is assumed rather than measured | Track governed-product usage, reporting lead time, and retirement of conflicting outputs. |

## Executive Interview Pitch

Northstar does not primarily have a dashboard problem. It has an accountability and decision-confidence problem. I would begin by agreeing the decisions and Tier-1 KPIs that matter, then assign domain owners who can approve definitions, quality expectations, and access. The target architecture uses Microsoft Fabric, OneLake, and Power BI to create reusable reporting-ready data products, but the platform is only an enabler. In the first 30 days I would inventory decisions, reports, sources, and quality issues, then select one product with visible business value. By day 90, leadership should have an approved source, clear ownership, measurable adoption, and a repeatable governance pattern. That creates evidence for scaling while avoiding a technology-first transformation.

## Assumptions and Ethical Use

- Northstar Retail Group is fictional.
- All maturity scores, targets, roles, and risks are scenario assumptions.
- The architecture is a proposal, not evidence of a deployed Microsoft Fabric environment.
- No confidential employer material should be added to this repository.

## What This Demonstrates

- Business-first data strategy
- Analytics and semantic architecture
- Domain ownership and data-product thinking
- Data governance and decision rights
- Phased transformation planning
- Executive communication and risk awareness

How to use this reference

Compare the section order with your preview. Check every table row plus each roadmap phase before committing.

This commit makes the completed leadership story public. Check the fictional boundaries before publishing so your portfolio remains employer-safe.

  • Confirm the preview contains no real employer names.
  • Confirm the preview contains no internal metrics.
  • Confirm the preview contains no credentials.
  • Select Commit changes... above the preview.
  • Select Commit changes in the commit dialog.

Your repository front page reloads with the completed case study. The roadmap now appears beneath the governed architecture.

  • Copy the public repository URL from your browser address bar.
  • Save it here for future applications: your public repository URL.

Before you test the public link, ask yourself which sections you expect a visitor to see beneath the governed architecture.

  • Use your browser menu to open a private browsing window.
  • Paste your public repository URL into the address bar.
  • Press Enter to load the public repository.

What should I see?

  • The four roadmap phases appear beneath the governed architecture.
  • The risk table follows the roadmap.
  • The executive pitch appears below the risk table.
  • The ethical-use statement follows the pitch.
  • The six proof points complete the page.

Public page missing your latest sections?

  • Return to the signed-in repository page.
  • Confirm the completed content appears on the repository front page.
  • Reload the visitor page after the commit completes.
  • Still stuck? Help me verify that my latest README commit is public.

That's the strategy complete. Your public case study now demonstrates delivery sequencing plus executive judgment.

Secret mission

Defend the Strategy in 90 Seconds

Your published case study shows your leadership judgment on the page. This challenge turns it into a focused 90-second defense for a hiring-manager conversation.

Clean Up Your Resources

Clean Up Your Resources

GitHub Free costs $0 USD per month for this use. Decide whether to keep your repository public, make it private while you revise it, or delete it entirely.

Resources you used:

  • One public prague-data-leadership-case-study repository containing the fictional case study in README.md.

Keep everything running

No action is needed. Choose this if you want the case study to remain available through its public URL.

  • Review README.md for real employer names, screenshots, data, credentials, internal metrics, or copied work products.
  • Remove any confidential information before sharing the repository URL.
  • Leave the prague-data-leadership-case-study repository public.
  • Open the repository URL in a signed-out browser window.
  • Confirm that visitors can see the complete fictional case study.

Pause - I'll come back to this later

Make the repository private while you revise the case study. Its content remains in your account while the public URL stops working for visitors.

  • Return to the prague-data-leadership-case-study repository.
  • Select Settings.
  • Find Change repository visibility.
  • Choose the private visibility option.
  • Review GitHub's visibility warnings.
  • Confirm the visibility change.
  • Open the repository URL in a signed-out browser window.
  • Confirm that visitors can no longer view the case study.

Delete - I don't want to use this again

Deleting the repository is destructive. GitHub notes that some deleted repositories can be restored within 90 days.

  • Return to the prague-data-leadership-case-study repository.
  • Select Settings.
  • Find Delete this repository.
  • Select Delete this repository.
  • Read the deletion warning carefully.
  • Complete the confirmation steps shown by GitHub.
  • Open the old repository URL in a signed-out browser window.
  • Confirm that the public case study is no longer available.

Nice Work!

Nice Work!

That is a strong finish. You published a complete data leadership case study in the public prague-data-leadership-case-study repository on GitHub.

Your artifact now demonstrates business judgment through a browser-only visual. You can use it to guide a focused hiring-manager conversation without exposing confidential information.

You've learned how to:

  • Frame a fictional analytics challenge around business outcomes. Make the case for trusted definitions before platform investment.
  • Design a governed target architecture with Microsoft Fabric as the shared platform boundary. Position OneLake as the home for governed data products. Use Power BI semantic models to supply reporting-ready models.
  • Turn the architecture into an executable leadership strategy. Assign accountability to domain owners. Give data stewards operational responsibility. Sequence delivery through a phased roadmap. Connect each major risk to a leadership response.
  • Complete the Secret Mission with a focused 90-second hiring-manager defense. State the business problem. Connect the platform choice to the fictional company's existing Power BI capability. Acknowledge the cost validation required for a real platform selection. Acknowledge the workload validation required for a real platform selection. Clarify domain-owner accountability. Clarify data-steward responsibility. Finish with the first 30-day delivery phase.

Ready to quiz yourself?