Lead BA Governance Playbook
Build a portfolio of Lead BA governance artifacts for a multi-workstream programme.
Introduction
30 Second Summary
When a company migrates from multiple legacy systems at once, every team has different priorities, timelines, and expectations. Without someone coordinating the business analysis effort across all workstreams, requirements fall through the cracks and stakeholder conflicts stall progress.
In this project, you will step into the Lead BA role for a multi-workstream digital transformation at a mid-sized insurance company. You'll produce a portfolio of interview-ready governance artifacts that demonstrate methodology ownership, cross-team coordination, and executive-level stakeholder management.
What You'll Build
Imagine opening your laptop before a Lead BA interview and walking the panel through a complete set of governance artifacts you built yourself, each one showing a different dimension of strategic BA leadership.
By the end of this project, you'll have:
- A BA Methodology document you can present in interviews to show how you'd coordinate 4 BAs with tailored techniques per workstream type, from regulation-heavy claims processing to user-facing portal design.
- A Stakeholder Power/Interest Map in Miro that reveals competing executive priorities and a targeted engagement strategy you can walk an interviewer through to demonstrate conflict resolution.
- A BA Governance Framework in Excel with decision rights, change control, and quality gates where you can trace any hypothetical scope change from initial request through to board resolution.
- A Work Package Assignment Matrix tracking 4 BAs across 4 workstreams with cross-team dependencies and weekly status reporting ready for a programme board.
- Secret Mission: Synthesize your entire governance approach into a 5-slide executive brief that sells your methodology to the programme board.
Are there any prerequisites?
This project assumes working knowledge of business analysis fundamentals including requirements gathering, process mapping, and stakeholder management. You should also have experience writing BRDs or user stories.
You'll need Microsoft Excel, Microsoft PowerPoint (or equivalent), and a free Miro account.
Before We Start
Before we dive in, let's lock in what you're about to build and why it matters.
You're stepping into the Lead BA role for a real governance challenge. Committing to the programme context now will sharpen every artifact you produce in the steps ahead.
Set Up Your Workspace
A Lead BA manages deliverables across multiple workstreams, multiple BAs, and multiple stakeholders. Without an organized workspace from day one, files get lost, naming conventions drift, and your governance artifacts lose the professional polish that makes them interview-ready.
In this step, you'll create a structured project folder, set up a Miro board for stakeholder mapping, and prepare your Excel governance workbook. The folder structure itself demonstrates governance thinking: each subfolder maps to a specific deliverable type.
In this step, get ready to:
- Create a project folder with 4 dedicated subfolders for each deliverable category.
- Set up a Miro board for stakeholder mapping and confirm it works.
- Create and save an Excel governance workbook with multiple tabs.
Create your project folder structure
Every governance artifact you build in this project needs a home. You'll create a top-level folder on your Desktop with one subfolder per deliverable type. This keeps your work organized the same way you'd organize a real programme's BA drive.
- Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
- Type Terminal (macOS) or PowerShell (Windows) and press Enter to open it.
- Move to your Desktop by running this command:
macOS
cd ~/Desktop
Windows
cd ~\Desktop
- Create the project folder and its subfolders by running these commands:
macOS
mkdir Meridian-BA-Governance
cd Meridian-BA-Governance
mkdir 01-Methodology 02-Stakeholder-Map 03-Governance-Framework 04-Work-Packages
Windows
mkdir Meridian-BA-Governance
cd Meridian-BA-Governance
mkdir 01-Methodology
mkdir 02-Stakeholder-Map
mkdir 03-Governance-Framework
mkdir 04-Work-Packages
- Confirm the folders exist by running:
ls
You should see all 4 subfolders listed: 01-Methodology, 02-Stakeholder-Map, 03-Governance-Framework, and 04-Work-Packages.
Don't see all 4 folders?
Make sure you ran the cd Meridian-BA-Governance command before creating subfolders. If you skipped it, the subfolders were created on your Desktop instead of inside the project folder.
If you see a "file already exists" error, the folder was already created. Run ls to confirm all 4 are present.
help me troubleshoot my folder structure
Create your Miro board
Miro is a collaborative whiteboard tool. You'll use it to build a visual stakeholder Power/Interest map that would be difficult to create in a spreadsheet. The visual layout makes competing priorities immediately obvious during an interview walkthrough.
- Open your browser and go to miro.com.
- Sign in to your Miro account.
- On your dashboard, click + Create new.
- Click Board from the menu that appears.
A new blank board opens in your browser.
- Click the board title at the top-left of the screen (it defaults to "Untitled").
- Type Meridian Insurance - Stakeholder Map and press Enter.
- Test that sticky notes work: click Sticky notes in the creation toolbar on the left side of the board, then click anywhere on the canvas to place one.
- Test that shapes work: click Shapes and lines in the creation toolbar, then drag a rectangle onto the canvas.
You should see both a sticky note and a rectangle shape on your board. This confirms you have full editing access.
Why Miro for stakeholder mapping?
A Power/Interest grid needs spatial positioning. You'll drag stakeholders into quadrants, draw conflict lines between them, and rearrange as your understanding deepens. Miro's infinite canvas makes this natural in a way that static spreadsheet cells cannot.
In an interview, you can screen-share the board and walk through your reasoning interactively.
Can't create a board?
If you see a message about permissions, you may need to join a team first. Click the plus icon in the sidebar of your dashboard to create your own free team, then try creating the board again.
The Miro Free plan allows up to 3 editable boards, so you have room for this project.
help me set up my Miro board
Set up the Excel governance workbook
Your governance framework will live in a multi-tab Excel workbook. Each tab will hold a different governance component: decision rights, change control, and quality gates. Setting it up now means you can jump straight into content in a later step.
- Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
- Type Excel and press Enter to open it.
- Create a new blank workbook.
- Save the file as BA-Governance-Framework.xlsx inside the 03-Governance-Framework subfolder on your Desktop (inside Meridian-BA-Governance).
- Confirm you can add multiple worksheet tabs: right-click any sheet tab at the bottom of the workbook and select Insert (or click the + icon next to the existing tab). You should see a second tab appear.
You now have a saved workbook with at least 2 tabs visible at the bottom. You'll rename and populate these tabs when you build the governance framework in Step 4.
Can't find the 03-Governance-Framework folder when saving?
When the Save dialog opens, navigate to your Desktop first, then open Meridian-BA-Governance, then open 03-Governance-Framework. If you don't see the folder, go back to your terminal and re-run ls inside Meridian-BA-Governance to confirm it exists.
help me save my Excel file in the right location
Before you move on, take a quick look at what you've set up. Do you think all three components are ready for the next steps?
- In your terminal, run ls inside Meridian-BA-Governance and confirm you see all 4 subfolders.
- Switch to your Miro browser tab and confirm you see the board titled Meridian Insurance - Stakeholder Map with your test sticky note and shape visible.
- Switch to Excel and confirm BA-Governance-Framework.xlsx is open with multiple tabs at the bottom.
All three are confirmed. Your workspace is organized and every tool is ready to receive content.
Your workspace mirrors the governance mindset you'll apply to the programme itself. Next up, you'll define the BA methodology that tells your team of 4 BAs exactly how to work across all workstreams.
Define the BA Methodology
Your project folder is ready and your tools are configured. Now it's time to produce the first governance artifact that defines how your BA team operates.
Without a methodology document, each of your 4 BAs will work differently. They'll produce inconsistent artifacts that can't be compared, reviewed, or quality-assured across workstreams. The methodology is the first thing a Lead BA establishes because it's the foundation every other governance artifact builds on.
In this step, get ready to:
- Create a BA Methodology document with 5 structured sections.
- Build a comparison table mapping tailored BA techniques to each workstream.
- Connect the methodology to the governance framework you'll build next.
Create the methodology document and write your first 3 sections
A Lead BA defines the methodology before any analysis work begins. This document tells your 4 BAs exactly what to produce, how to produce it, and what standard it must meet.
- Open Word (or your preferred document editor).
- Create a new document and save it as BA-Methodology-Approach.docx in your 01-Methodology folder inside Meridian-BA-Governance.
- Add a document title at the top: "BA Methodology and Approach - Meridian Insurance Platform Migration".
Now build out the first 3 sections of the document.
- Write Section 1: Programme Context. Include 2-3 sentences describing Meridian's situation: a mid-sized insurer (150 employees) migrating from 3 legacy systems to a unified platform across 4 workstreams (Claims Processing, Policy Administration, Customer Portal, Data Migration). State the 18-month programme timeline with Phase 1 spanning 3 months.
- Write Section 2: BA Approach. State that you are using a hybrid methodology (combining predictive and adaptive elements). Justify your choice: the programme's complexity and regulatory environment (insurance) demand the rigour of predictive planning, while the Customer Portal workstream benefits from iterative, adaptive delivery.
- Write Section 3: Deliverables Standard. List the mandatory deliverables every BA must produce per workstream: a current-state process map, a requirements document, and a traceability matrix.
Why a hybrid approach?
A purely predictive (waterfall) approach would slow down the Customer Portal, which needs user feedback loops. A purely adaptive (agile) approach would lack the audit trail that Claims Processing needs for regulatory compliance.
Hybrid lets you apply the right rigour to each workstream while maintaining a consistent governance layer across all of them. This is a common Lead BA decision in regulated industries.
- Save your document.
- Review what you have so far: your document should have a title and 3 clearly labelled sections with content in each.
Unsure what to write for Programme Context?
Keep it factual and concise. You are setting the scene for a reader who doesn't know the programme. Stick to: who (Meridian Insurance, 150 employees), what (migrating 3 legacy systems to 1 unified platform), how (4 workstreams), and when (18 months total, Phase 1 = 3 months).
Help me write a Programme Context section for my BA methodology document.
Populate the techniques by workstream comparison table
Each workstream has a different nature. Claims Processing is regulation-heavy. Customer Portal is user-facing and iterative. A Lead BA demonstrates competence by selecting and adapting techniques to match each workstream's needs rather than applying a one-size-fits-all approach.
- In your document, scroll to Section 4: Techniques by Workstream.
- Create a comparison table with 4 rows (one per workstream) and 3 columns: Workstream, Selected Techniques, and Justification.
Populate each row with the following technique selections:
- Claims Processing: document analysis, process modelling, workshops. Justification: regulation-heavy workstream requires thorough documentation of existing rules and formal process flows. Workshops engage claims SMEs who hold undocumented knowledge.
- Policy Administration: document analysis, interviews, process modelling. Justification: complex business rules embedded in legacy systems require detailed document review. Interviews surface tacit knowledge from underwriters. Process modelling captures end-to-end policy lifecycle.
- Customer Portal: prototyping, user story mapping, workshops. Justification: user-facing workstream benefits from visual prototypes and iterative feedback. User story mapping aligns the team on customer journeys. Workshops bring together customer service reps and UX designers.
- Data Migration: data modelling, document analysis, interviews. Justification: 3 legacy systems with overlapping data structures require formal data modelling. Document analysis maps existing schemas. Interviews with data stewards clarify transformation rules.
What does this table demonstrate in an interview?
This table shows you can select and adapt methodologies for complex programmes rather than defaulting to a generic approach. That's a Lead BA competency: defining new approaches for the practice, not just following existing ones.
The BABOK Guide v3 lists these exact techniques (document analysis, interviews, process modelling, workshops, prototyping) under Plan Business Analysis Approach. Referencing BABOK in an interview shows your choices are grounded in industry standards, not invented on the spot.
- Save your document.
- Check that each workstream row has a different combination of techniques. No two workstreams should have identical technique selections.
Struggling to differentiate the technique selections?
Ask yourself: what is the primary challenge of this workstream? For Claims Processing, it's regulatory accuracy. For Customer Portal, it's user experience. Let the challenge drive your technique choice.
Help me choose the right BA techniques for each workstream.
Write quality standards and the governance integration paragraph
A methodology without quality gates is a suggestion, not a standard. Section 5 defines how deliverables get reviewed and approved, so your BAs know exactly what "done" looks like.
- Write Section 5: Quality Standards. Define a 3-stage review and sign-off process:
- Stage 1 - Peer Review: Another workstream BA reviews the deliverable for consistency, completeness, and alignment with the methodology.
- Stage 2 - Lead BA Review: You (as Lead BA) review for cross-workstream alignment, governance compliance, and strategic fit.
- Stage 3 - Stakeholder Sign-off: The appropriate decision maker approves the deliverable per the Decision Rights matrix you'll create in Step 4.
- Under each stage, add acceptance criteria (what the reviewer checks) and a revision cycle (e.g., 2 working days for peer review, 1 working day for Lead BA review).
- Save your document.
Now add the final paragraph that ties everything together.
- At the end of the document, add a heading called "Governance Integration".
- Write a paragraph (3-4 sentences) explaining how this methodology connects to the broader governance framework. State that all BA deliverables will follow this methodology, be tracked in the work package matrix, and go through the governance approval process.
- Save your final document.
Why include a governance integration paragraph?
This paragraph shows an interviewer that you think systemically. A methodology that exists in isolation is just a document. A methodology that explicitly links to tracking and approval processes is an operational tool.
In the next steps, you'll build the governance framework and work package matrix that this paragraph references. The forward references demonstrate you've planned the full system, not just one piece.
Before you review your finished document, think about this: if you handed this methodology to a new BA joining the programme on day one, would they know exactly what to produce and to what standard?
- Scroll through your completed BA-Methodology-Approach.docx from top to bottom.
- Confirm you have all 5 sections populated: Programme Context, BA Approach, Deliverables Standard, Techniques by Workstream, and Quality Standards.
- Confirm the Governance Integration paragraph is at the end.
- Verify that each workstream in your techniques table has a distinct combination of techniques with a justification that differs from the others.
What should I see?
Your document should be approximately 2 pages long. Each section has clear headings and substantive content (not just bullet placeholders). The techniques table is the visual centrepiece, showing at a glance how your approach adapts to each workstream.
Your methodology is locked in. Every BA on your team now knows what to produce, how to produce it, and what quality bar to meet. Next up, you'll map the stakeholders who hold power over this programme and uncover the conflicts hiding between them.
Map Stakeholders and Identify Conflicts
Your methodology document gives your BA team a consistent way of working. But consistency alone won't keep the programme on track when executives disagree on priorities.
With 4 workstreams and multiple executives, you will inevitably face situations where stakeholders want different things. Until you map who has power, who has interest, and where their objectives clash, you have no strategy for navigating these conflicts. This step reveals the problem that your governance framework will solve in the next step.
In this step, get ready to:
- Plot at least 8 stakeholders on a Power/Interest grid in Miro.
- Document at least 2 specific conflicts between high-power stakeholders.
- Build an engagement strategy defining how you'll communicate with each key stakeholder.
Draw the Power/Interest grid and plot stakeholders
A Power/Interest grid is one of the most effective tools for stakeholder analysis. It reveals not just who matters, but how to engage them based on their ability to influence outcomes and their level of involvement.
- Switch back to your Miro board ("Meridian Insurance - Stakeholder Map").
- Draw a large 2x2 grid using a square shape or the frame tool. Label the X-axis "Interest" (Low to High, left to right) and the Y-axis "Power" (Low to High, bottom to top).
- Label each quadrant:
You should now see a clean 2x2 grid with all four quadrants labelled.
- Add sticky notes for each of the following stakeholders and place them in the correct quadrant based on their power and interest level:
- Manage Closely (High Power / High Interest): VP Claims (wants fast claims turnaround, opposes delays), CTO (wants architecture purity, resists shortcuts), COO (wants minimal operational disruption during migration), Programme Manager (owns timeline).
- Keep Satisfied (High Power / Low Interest): CFO (wants cost containment, skeptical of scope expansion).
- Keep Informed (Low Power / High Interest): Head of Customer Service (champion of Customer Portal), Data Governance Manager (owns data quality standards), the 4 Workstream BAs you're leading.
Make each sticky note useful
On each sticky note, write the stakeholder's name and a short phrase capturing their primary objective or concern. For example: "VP Claims — fast claims turnaround". This makes the grid scannable at a glance when you present it in interviews.
- Count your sticky notes to confirm you have at least 8 stakeholders plotted across the grid (4 in Manage Closely, 1 in Keep Satisfied, 3+ in Keep Informed).
Your Miro board should now show a populated grid where you can immediately see that most of the high-power stakeholders sit in the "Manage Closely" quadrant. That density is a signal: multiple powerful people with competing interests, all watching closely.
Grid looking cluttered?
If sticky notes overlap in the Manage Closely quadrant, spread them out within that quadrant. Relative positioning within a quadrant still matters. The Programme Manager might have slightly less power than the CTO, so place them slightly lower.
Help me organize my Power/Interest grid so stakeholders are clearly positioned.
Document the conflicts between executives
A grid tells you where stakeholders sit. It does not tell you where they collide. The real value for a Lead BA is spotting conflicts before they stall delivery.
- Below your Power/Interest grid on the Miro board, add a new section heading: "Conflict Map".
- Create the first conflict entry. Add a sticky note or text box documenting:
- Create the second conflict entry:
Step back and look at your board. You've just made something visible that would otherwise stay hidden until it derails a delivery.
Why these conflicts matter right now
Both conflicts involve high-power stakeholders who can block progress. Without a mechanism to resolve them, your BAs will receive contradictory direction. One BA gets told "move fast" by VP Claims. Another gets told "do it properly" by the CTO.
You've identified the problem. You don't have the solution yet. That's intentional. The governance framework in the next step will provide the decision rights and escalation paths that resolve these conflicts.
Not sure if your conflicts are realistic enough?
A good conflict has three properties: both parties are reasonable (neither is "wrong"), the tension is structural (it comes from different accountabilities, not personality), and it requires a decision that can't satisfy both parties fully. If your conflict entries meet all three, they'll hold up in an interview.
Help me evaluate whether my stakeholder conflicts are interview-ready.
Build the engagement strategy
Knowing where stakeholders sit and where they clash is only useful if you have a plan for engaging them. The engagement strategy translates your map into concrete actions: who gets what information, how often, and in what format.
- Decide where to create your Engagement Strategy table. You can build it directly on your Miro board (below the Conflict Map) or as a separate Excel file saved in your 02-Stakeholder-Map folder. Either approach works for interview presentation.
- Create a table with 5 columns: Stakeholder, Communication Frequency, Preferred Format, Key Concerns, Engagement Tactic.
- Populate a row for each stakeholder in the Manage Closely and Keep Satisfied quadrants. Use these as a guide:
Why tailor the format to each stakeholder?
A CFO who receives a 10-page requirements document will never read it. A CTO who gets a one-line Slack update will feel out of the loop. Matching the communication format to the stakeholder's preferences and role shows you understand executive communication. This is a core Lead BA differentiator.
- Review your completed engagement strategy table. Confirm each Manage Closely and Keep Satisfied stakeholder has all 4 fields populated (frequency, format, concerns, tactic).
- If you created the table in Excel, save it as Engagement-Strategy.xlsx in your 02-Stakeholder-Map folder.
Engagement tactics feeling generic?
If your tactics sound like "keep them informed" or "manage expectations", they're too vague. Each tactic should name what specific information this stakeholder needs and how it relates to their stated concern. The VP Claims doesn't need "regular updates". They need delivery velocity data because their concern is speed.
Help me make my engagement tactics more specific and actionable.
Before you move on, look at your Miro board as a whole. You should see a Power/Interest grid with at least 8 stakeholders, a Conflict Map documenting 2 specific executive tensions, and an engagement strategy covering every high-power stakeholder.
What does your board prove in an interview?
This single Miro board demonstrates three Lead BA capabilities: structured analysis (the grid), conflict anticipation (the map), and strategic communication planning (the engagement table). When presenting it, walk through the logic: "I mapped power and interest, which revealed these conflicts, which informed this engagement approach."
You've exposed the problem. Two sets of powerful executives pulling in opposite directions with no mechanism to resolve the tension. Your BAs will get conflicting instructions unless you establish clear decision rights and escalation paths. That's exactly what you'll build next.
Build the BA Governance Framework
Your stakeholder map just revealed a critical problem. At least two pairs of powerful executives want different things, and without a mechanism to resolve those conflicts, your workstreams will stall.
A BA Governance Framework defines who makes what decisions, how changes get escalated, and when approvals are required. It turns those competing priorities into a structured process that keeps delivery moving. In this step, you'll build the framework that directly addresses the VP Claims vs. CTO and CFO vs. COO conflicts you identified.
In this step, get ready to:
- Build a Decision Rights matrix defining who owns each type of BA decision.
- Document a Change Control process with classification levels and escalation paths.
- Define Quality Gates that every BA deliverable must pass before sign-off.
Create the Decision Rights tab
Decision rights answer the question: when a disagreement happens, who gets the final say? Without this clarity, conflicts like VP Claims vs. CTO become endless debates with no resolution path.
- Return to your BA-Governance-Framework.xlsx file in the 03-Governance-Framework folder.
- Rename the first worksheet tab to Decision Rights.
- Create column headers in Row 1: Decision Type, Decision Maker, Consulted, Informed, Escalation Trigger.
- Populate 6 rows, one for each decision type:
- Row 2 — Requirements sign-off. Decision Maker: Workstream Sponsor. Consulted: Lead BA, relevant SMEs. Informed: Programme Manager. Escalation Trigger: disputed requirements unresolved after 2 review cycles.
- Row 3 — Scope change (minor). Decision Maker: Programme Manager. Consulted: Lead BA. Informed: Workstream BAs. Escalation Trigger: cost impact exceeds your defined threshold or timeline impact over 2 weeks.
- Row 4 — Scope change (major). Decision Maker: Steering Committee. Consulted: Programme Manager, Lead BA, CTO. Informed: all workstream sponsors. Escalation Trigger: any cross-workstream impact or budget reallocation required.
- Row 5 — Cross-workstream dependency resolution. Decision Maker: Lead BA. Consulted: affected workstream BAs. Informed: Programme Manager. Escalation Trigger: BAs cannot agree within 3 working days.
- Row 6 — Methodology deviation. Decision Maker: Lead BA. Consulted: requesting workstream BA. Informed: Programme Manager. Escalation Trigger: deviation affects deliverable comparability across workstreams.
- Row 7 — Deliverable quality dispute. Decision Maker: Lead BA. Consulted: Peer reviewer, workstream BA. Informed: Programme Manager. Escalation Trigger: dispute unresolved after Lead BA mediation.
Why these 6 decision types?
These cover the decisions a Lead BA encounters most frequently: who signs off work, what happens when scope shifts, how conflicts between workstreams resolve, and what to do when quality is disputed.
Notice that you own cross-workstream dependencies, methodology deviations, and quality disputes directly. The Programme Manager and Steering Committee only get involved for scope changes with budget or timeline impact. This is intentional. It gives you operational authority while reserving strategic decisions for governance boards.
- Save the file.
- Check your Decision Rights tab. You should see 6 clearly populated rows with different decision makers assigned based on impact level.
How this connects to your conflict map
Remember the VP Claims vs. CTO conflict? If VP Claims requests a scope change that impacts architecture, the CTO is listed as Consulted in the major scope change row. This means the CTO gets a voice but doesn't have veto power. The Steering Committee makes the final call. Your framework just created the resolution mechanism for that conflict.
Document the Change Control process
Decision Rights tell you who decides. Change Control tells you how those decisions get made. It's the step-by-step process a change follows from the moment someone requests it to the moment it's communicated.
- Create a new worksheet tab in your workbook and name it Change Control.
- Create column headers: Step #, Process Step, Responsible Role, Timeframe, Output Document.
- Populate 6 rows for the change control flow:
- Step 1 — Change requested by BA or stakeholder. Responsible: Requesting party. Timeframe: N/A. Output: Change Request Form.
- Step 2 — Lead BA assesses impact across workstreams. Responsible: Lead BA. Timeframe: 2 working days. Output: Impact Assessment.
- Step 3 — Classification: minor (Lead BA approves), moderate (Programme Manager approves with Lead BA recommendation), major (Steering Committee with full impact assessment). Responsible: Lead BA. Timeframe: 1 working day. Output: Classification Decision.
- Step 4 — Cross-workstream impact check: if the change affects more than one workstream, mandatory dependency review. Responsible: Lead BA + affected workstream BAs. Timeframe: 2 working days. Output: Dependency Impact Report.
- Step 5 — Decision recorded in decision log. Responsible: Lead BA. Timeframe: same day as decision. Output: Updated Decision Log.
- Step 6 — Communication to affected parties per engagement strategy. Responsible: Lead BA. Timeframe: 1 working day. Output: Stakeholder Communication (format per engagement strategy).
What makes this Lead-level governance?
Notice that you, as Lead BA, sit at the centre of every step. You assess impact, you classify the change, you trigger the dependency review, and you own communication. The Programme Manager and Steering Committee only appear for moderate and major changes.
This demonstrates ownership of the process without overstepping into programme-level authority. In an interview, you can explain exactly where your decision boundary ends and governance escalation begins.
- Save the file.
- Review your Change Control tab. You should see a clear 6-step flow with timeframes that show a change can move from request to communication within 5-7 working days for a minor change.
Define the Quality Gates
Your methodology (from Step 2) defines what deliverables each BA produces. Quality Gates define how you know those deliverables are actually good enough. Without gates, you're trusting that 4 different BAs all meet the same standard independently.
- Create a new worksheet tab and name it Quality Gates.
- Create column headers: Gate Name, Reviewer, Entry Criteria, Review Checklist, Exit Criteria, If Failed.
- Populate Gate 1 — Peer Review:
- Reviewer: Another workstream BA (not the author).
- Entry Criteria: Deliverable is complete per the methodology standard, all sections populated, author self-review done.
- Review Checklist (5 items): (1) Consistent with methodology template. (2) Requirements are testable and unambiguous. (3) Traceability links to business objectives present. (4) No conflicts with other workstream deliverables. (5) Stakeholder language appropriate for audience.
- Exit Criteria: All checklist items pass, or exceptions documented and accepted.
- If Failed: Return to author with specific feedback. Author revises and resubmits within 2 working days.
- Populate Gate 2 — Lead BA Review:
- Reviewer: Lead BA (you).
- Entry Criteria: Peer Review gate passed.
- Review Checklist (4 items): (1) Cross-workstream alignment verified (no contradictions with other deliverables). (2) Governance compliance confirmed (follows decision rights and change control). (3) Strategic fit with programme objectives. (4) Dependencies identified and logged.
- Exit Criteria: Lead BA signs off with no outstanding cross-workstream issues.
- If Failed: Lead BA identifies specific cross-workstream issues. Joint review meeting with affected BAs within 3 working days.
- Populate Gate 3 — Stakeholder Sign-off:
- Reviewer: Decision Maker per the Decision Rights matrix.
- Entry Criteria: Lead BA Review gate passed. Stakeholder briefing completed.
- Review Checklist (3 items): (1) Business requirements accurately reflect stakeholder needs. (2) Acceptance criteria are achievable within constraints. (3) No unresolved objections from consulted parties.
- Exit Criteria: Formal sign-off recorded in decision log.
- If Failed: Objections documented. Lead BA facilitates resolution session. Re-submission after objections addressed.
Why 3 gates and not 1?
Each gate catches different problems. Peer Review catches internal quality issues (typos, ambiguity, template compliance). Lead BA Review catches cross-workstream conflicts that a single workstream BA wouldn't see. Stakeholder Sign-off catches misalignment between what was documented and what the business actually needs.
A single combined review would miss cross-workstream issues entirely because no stakeholder has visibility across all four workstreams. Only you, as Lead BA, have that view.
- Save your workbook.
- Switch between your three tabs (Decision Rights, Change Control, Quality Gates). You should see a populated matrix on each tab with no empty cells in your main data area.
Now test whether your framework actually works end-to-end. Imagine VP Claims contacts you and says: "We need to add automated fraud scoring to the claims workflow. The vendor says it's a 4-week addition."
Before you trace this through your framework, predict: based on what you built, which classification would this change receive, and who makes the final decision?
- Trace the scenario through your Change Control tab: VP Claims submits the request (Step 1). You assess impact and find it affects Claims Processing timeline by 4 weeks and requires CTO input on architecture (Step 2). You classify it as major because the timeline impact exceeds 2 weeks (Step 3).
- Check the Decision Rights tab: for a major scope change, the Steering Committee decides. CTO is consulted (architecture impact). All workstream sponsors are informed.
- Check the Quality Gates tab: once the change is approved and your BA documents the updated requirements, those requirements will flow through all 3 gates before sign-off.
If you can trace a scenario from request through classification, decision, and quality review, your framework is complete and interview-ready.
Can't trace the scenario cleanly?
If you hit a gap where you don't know what happens next, that's the gap to fill. Common issues:
- The escalation trigger in Decision Rights doesn't clearly match the classification criteria in Change Control. Make sure the threshold in one tab (e.g., timeline impact over 2 weeks) maps directly to a classification level in the other.
- The "Consulted" column in Decision Rights doesn't mention a role that the Change Control process sends the change to. Align the roles across both tabs.
Ask for help tracing a governance scenario through my framework.
Your governance framework now has teeth. It defines who decides, how decisions flow, and what quality bar every deliverable must clear. Next, you'll make governance operationally visible by assigning work packages to your 4 BAs with timelines, dependencies, and progress tracking.
Create the Work Package Assignment Matrix
Your governance framework now defines how decisions get made, how changes flow through the programme, and what quality looks like. That's the mechanism for control. But your 4 BAs still don't know what they're delivering, by when, or how their work connects to other workstreams.
Without a work package matrix, you can't track progress, spot bottlenecks, or give the programme board an honest status update. This step is where your governance becomes operationally visible.
In this step, get ready to:
- Build an Assignment Matrix tracking 12 work packages across 4 workstreams.
- Create a Dependency Tracker that makes cross-workstream blockers visible.
- Design a Weekly Status View dashboard with conditional formatting for team meetings.
Build the Assignment Matrix tab
Each workstream needs a clear list of deliverables with owners, dates, and status. The Assignment Matrix is the single view that tells every BA exactly what's on their plate.
- Open Excel and create a new workbook.
- Save it as Work-Package-Matrix.xlsx in the 04-Work-Packages folder inside your Meridian-BA-Governance project folder.
- Rename the first worksheet tab to Assignment Matrix.
- In row 1, create these column headers:
- Work Package ID in cell A1.
- Workstream in cell B1.
- Work Package Name in cell C1.
- Assigned BA in cell D1.
- Start Date in cell E1.
- End Date in cell F1.
- Status in cell G1.
- Dependencies in cell H1.
- Notes in cell I1.
Now populate the matrix with 12 work packages. You need 3 per workstream, each assigned to a fictional BA with realistic Phase 1 dates spanning the 3-month period.
- Add the Claims Processing workstream first. Enter these 3 rows:
- CP-01 | Claims Processing | Document current claims adjudication rules | (BA name, e.g. Sarah Chen) | a start date in Week 1 | an end date in Week 3 | In Progress | None | (any relevant notes).
- CP-02 | Claims Processing | Map claims data entities and relationships | (same BA) | a start date in Week 3 | an end date in Week 6 | Not Started | Depends on CP-01 | (any relevant notes).
- CP-03 | Claims Processing | Define future-state claims workflow requirements | (same BA) | a start date in Week 6 | an end date in Week 10 | Not Started | Depends on CP-02 | (any relevant notes).
- Add 3 rows for Policy Administration (IDs: PA-01, PA-02, PA-03). Assign a different fictional BA (e.g. Marcus Johnson). Choose work packages relevant to policy admin such as documenting policy lifecycle rules, mapping policy data structures, and defining renewal workflow requirements.
- Add 3 rows for Customer Portal (IDs: CUP-01, CUP-02, CUP-03). Assign a third BA (e.g. Priya Patel). Choose user-facing work packages such as mapping customer journeys, defining portal requirements, and prototyping key interactions.
- Add 3 rows for Data Migration (IDs: DM-01, DM-02, DM-03). Assign a fourth BA (e.g. James O'Brien). Include packages like defining data extraction scope, extracting and mapping legacy claims data, and building data validation rules.
- For the Status column, use one of these four values per row: Not Started, In Progress, In Review, or Complete. Make at least one package Complete and at least two In Progress to simulate a realistic mid-phase snapshot.
- Save the file.
You should now see 12 populated rows beneath your header, with 4 distinct BA names and a mix of statuses across the workstreams.
Why 3 work packages per workstream?
Three packages per workstream is enough to show a realistic delivery sequence (discover, model, define) without overwhelming the matrix. In a real programme, you might have 8-15 per workstream.
For interview purposes, 3 demonstrates that you understand sequencing and dependencies without creating a spreadsheet that's too dense to walk through.
Dates not looking right?
Make sure your date columns are formatted as dates (right-click the column, select Format Cells, choose Date). If Excel is interpreting your dates as text, the matrix won't sort chronologically.
Help me fix my date formatting
Create the Dependency Tracker
Individual work packages don't exist in isolation. When DM-02 (extracting legacy claims data) depends on CP-02 (mapping claims data entities) being finished first, a delay in Claims Processing directly blocks Data Migration. The Dependency Tracker makes these invisible connections visible and actionable.
- Click the + button next to your Assignment Matrix tab at the bottom of the workbook to add a new worksheet.
- Rename the new tab to Dependency Tracker.
- Create these column headers in row 1:
- Dependency ID in A1.
- Source Work Package in B1.
- Target Work Package in C1.
- Dependency Type in D1.
- Impact if Delayed in E1.
- Status in F1.
- Owner in G1.
Now populate at least 4 cross-workstream dependencies. These are situations where one workstream's output feeds directly into another workstream's input.
- Enter your first dependency: DEP-01 | Source: CP-02 (Map claims data entities) | Target: DM-02 (Extract and map legacy claims data) | Type: Finish-to-Start | Impact: DM-02 cannot begin until CP-02 completes, blocking entire Data Migration timeline | Status: At Risk | Owner: (the Lead BA, i.e. you).
- Enter a second dependency: DEP-02. Think about which other workstreams share data or deliverables. For example, the Customer Portal team might need Policy Administration's data structures before they can build the portal's policy display. Choose a Dependency Type of Finish-to-Start, Information, or Shared Resource.
- Enter a third dependency: DEP-03. Look for a case where Data Migration needs output from Policy Administration.
- Enter a fourth dependency: DEP-04. Identify one more cross-workstream connection. Consider whether the Customer Portal needs validated data from the Data Migration workstream before user acceptance testing.
- Save the file.
Check your Dependency Tracker tab. You should see at least 4 rows, each connecting a work package from one workstream to a work package in a different workstream.
What makes dependencies actionable?
The Impact if Delayed column is what transforms this from a passive record into a governance tool. When you write "DM-02 cannot begin, blocking entire Data Migration timeline", you're giving the programme board a concrete reason to prioritise CP-02 if it starts slipping.
In an interview, you can point to this tracker and say: "This is how I made invisible risks visible to the programme board."
Struggling to identify dependencies?
Ask yourself: "Which workstream produces something that another workstream consumes?" Data models feed into migration scripts. Business rules feed into portal logic. If workstream A's output is workstream B's input, that's a dependency.
Help me identify cross-workstream dependencies
Build the Weekly Status View
Your Assignment Matrix and Dependency Tracker hold the detail. But when you walk into your weekly BA team meeting, you need a dashboard that answers one question in 10 seconds: where are we stuck?
- Add a third worksheet tab and rename it to Weekly Status View.
- Create these column headers in row 1: Workstream, Total Packages, Completed, In Progress, Blocked, Key Risk.
- Populate 4 rows, one per workstream. Use sample data that tells a realistic story. For Claims Processing, enter: 3 total packages, 1 completed, 1 in progress, 1 not started, with the key risk being "CP-02 delayed due to SME availability".
- Fill in Policy Administration, Customer Portal, and Data Migration rows with their own counts and risks. Make at least one workstream fully green (on track) and at least one amber or red.
Now add conditional formatting to make the status immediately scannable.
- Select the Blocked column cells (rows 2-5).
- Click Home in the ribbon, then click Conditional Formatting.
- Select Highlight Cells Rules, then Greater Than. Set the value to 0 and choose a red fill. This highlights any workstream with blocked packages.
- Apply a similar rule to the Key Risk column: select cells with text, and format with an amber fill for any non-empty cell.
- For workstreams with no blocks and no risk, manually set a green background on the Workstream name cell to indicate on-track status.
- Save the file.
Your Weekly Status View should now show colour-coded rows. Red cells draw the eye to blocked workstreams, amber flags risks, and green confirms what's on track.
Why conditional formatting matters for governance
In a real programme, you'd update this view every Friday and share it in your BA team standup on Monday morning. The colours let you skip the "let me read through all the data" phase and jump straight to "here's where we need to act."
This is what Lead BA governance looks like in practice: turning raw data into instant, actionable signals.
Conditional formatting not applying?
Make sure you're selecting the data cells (row 2 onwards), not the header row. Also check that the Blocked column contains numbers (not text like "none"). Conditional formatting rules compare against the data type in the cells.
Help me troubleshoot conditional formatting
Before you move on, take a moment. What do you expect to see if you flip between all three tabs in this workbook?
Click through your three tabs: Assignment Matrix, Dependency Tracker, Weekly Status View. You should see 12 work packages with 4 BA names and Phase 1 dates, at least 4 cross-workstream dependencies with impact statements, and a colour-coded dashboard that highlights blocked workstreams in red.
Your operational governance layer is now complete. You have methodology, stakeholder strategy, decision rights, and work package tracking. Next up in the Secret Mission, you'll synthesize all of this into a 5-slide executive brief that sells your approach to the programme board.
Secret mission
Build the Executive Brief
A Lead BA who can't communicate their approach to a programme board in 5 minutes won't get buy-in for their governance model. In this secret mission, you'll synthesize all four governance artifacts into a 5-slide executive brief that sells your approach in business outcomes, not BA jargon.
Clean Up Your Resources
Clean Up Your Resources
Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely locally (plus one Miro board), so there are no ongoing costs.
Resources you used:
- Meridian-BA-Governance folder on your Desktop (contains all deliverables across 4 subfolders plus the Executive Brief).
- Miro board: "Meridian Insurance - Stakeholder Map" (Power/Interest grid, Conflict Map, Engagement Strategy).
Keep everything running
No action needed. Choose this if you're still actively refining your governance artifacts or preparing for an upcoming interview.
- Your Meridian-BA-Governance folder stays on your Desktop, ready for edits.
- Your Miro board remains accessible from your Miro dashboard. The Free plan allows up to 3 editable boards, and this project uses 1.
- Excel and PowerPoint files stay in their subfolders. You can open and update them any time.
Pause - I'll come back to this later
Shut down any open applications to free up memory, but keep your files in place for later.
- Save and close any open Excel workbooks, PowerPoint files, or Word documents from this project.
- Close any open Miro browser tabs. Your board saves automatically and will be there when you return.
- Your Meridian-BA-Governance folder remains on your Desktop untouched.
Delete - I don't want to use this again
Remove all project resources and start fresh. Only choose this if you've exported or backed up anything you want to keep.
- Delete the Miro board. Open your Miro dashboard, find the "Meridian Insurance - Stakeholder Map" board, open the board menu, and select the option to delete it. Confirm the deletion when prompted.
- Delete the project folder. On macOS, open Terminal and run the command below. On Windows, open PowerShell and run the Windows command below.
macOS/Linux:
rm -rf ~/Desktop/Meridian-BA-Governance
Windows (PowerShell):
Remove-Item -Recurse -Force "$HOME\Desktop\Meridian-BA-Governance"
- Confirm the folder is gone by checking your Desktop. You should no longer see Meridian-BA-Governance listed.
That's a Wrap!
That's a Wrap!
Nice work. You've just built a complete Lead BA Governance Playbook for a multi-workstream digital transformation at Meridian Insurance.
Here's what you accomplished:
- Defined a BA Methodology that tailors techniques per workstream type, giving 4 BAs a consistent operating model across Claims Processing, Policy Administration, Customer Portal, and Data Migration.
- Mapped stakeholders on a Power/Interest Grid in Miro, identified competing executive priorities, and built a targeted Engagement Strategy that navigates real conflicts between high-power decision-makers.
- Produced a BA Governance Framework with decision rights, change control, and quality gates, paired with a Work Package Assignment Matrix tracking cross-workstream dependencies and weekly status reporting.
- Secret Mission: Synthesized the entire governance approach into a 5-slide Executive Brief that sells your methodology, stakeholder strategy, and governance model to a programme board in under 5 minutes.
Ready to quiz yourself?