BA Project Initiation and Stakeholder Discovery

Build a stakeholder register, Power/Interest grid, MOM, and RACI matrix.

Introduction

30 Second Summary

Every major project has a moment where someone realizes the wrong people were left out of a critical decision. In aviation maintenance, where a missed stakeholder can delay a fleet-wide system rollout, that moment is expensive.

In this project, you will step into the role of a junior Business Analyst at Infosys, assigned to help AAR Corp modernize its legacy MRO systems across multiple facilities. You'll build every foundational artifact a BA creates in their first two weeks on a real consulting engagement.

What You'll Build

You'll hand your project lead a complete set of initiation artifacts and watch them approve you to run the next discovery session on your own.

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

  • A Project Context Summary that lets you brief anyone on the client's business, the project's purpose, and what gaps are worth investigating, without ever referencing the original Statement of Work.
  • A Stakeholder Register and Power/Interest grid that show you exactly who can approve, block, or champion the modernization, and how to prioritize your engagement with each of them.
  • A complete preparation-to-follow-up cycle: you'll walk into a discovery session with targeted questions, handle unexpected stakeholder revelations, and walk out with a formal MOM and RACI matrix documenting every decision, action item, and line of accountability.
  • Secret Mission: Build a Stakeholder Communication Plan that turns your stakeholder analysis into an ongoing operational plan for how, when, and what you communicate to each group throughout the project.

Is this part of a series?

This is Project 1 of 6 in the AAR-Infosys BA Simulation Series. No prior experience is required.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters.

You're about to step into the role of a junior Business Analyst at Infosys, assigned to the AAR Legacy Integration Modernization and Operations Transformation project. Understanding the business context and stakeholder landscape is the very first thing a BA does on any engagement, because every requirement you gather later depends on knowing who you're building for and why.

Set Up Your BA Workspace

On a real consulting engagement, the way you organize your work signals your readiness to senior stakeholders. Documents scattered across your desktop or saved in random folders tell a project lead you're not prepared.

In this step, you'll build a professional workspace for the AAR project. You'll create an organized folder structure, open your diagramming tool, and prepare your first project document with a professional header.

In this step, get ready to:
  • Create an organized project folder structure on your local machine.
  • Open diagrams.net for stakeholder mapping and process diagrams.
  • Set up a Word document with a professional header for your Project Context Summary.
Create your project folder structure

Consulting firms organize engagement artifacts into numbered folders from day one. The numbered prefixes keep subfolders in a consistent order across every team member's machine.

  • 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 your project folder and subfolders by running these commands:

macOS

mkdir -p AAR_Legacy_Modernization/01_Project_Context
mkdir -p AAR_Legacy_Modernization/02_Stakeholder_Analysis
mkdir -p AAR_Legacy_Modernization/03_Meeting_Notes
mkdir -p AAR_Legacy_Modernization/04_Templates

Windows

mkdir AAR_Legacy_Modernization\01_Project_Context
mkdir AAR_Legacy_Modernization\02_Stakeholder_Analysis
mkdir AAR_Legacy_Modernization\03_Meeting_Notes
mkdir AAR_Legacy_Modernization\04_Templates
  • Confirm the folders exist by running:
ls AAR_Legacy_Modernization

You should see four subfolders listed: 01_Project_Context, 02_Stakeholder_Analysis, 03_Meeting_Notes, and 04_Templates.

Why numbered prefixes?

The numbers 01_ through 04_ force your operating system to sort folders in project-phase order. Without them, folders sort alphabetically and your engagement artifacts end up jumbled.

Not seeing the folders?

Make sure you ran the cd ~/Desktop (macOS) or cd ~\Desktop (Windows) command first. If you skipped it, your folders may have been created in a different location.

Check that each folder name matches exactly, including underscores. A typo in the folder name now means misplaced files later.

Help me find where my folders were created.

Open diagrams.net in your browser

You'll use diagrams.net (also called draw.io) to create your stakeholder Power/Interest grid later in the project. It is free, runs entirely in the browser, and requires no account.

  • Open your web browser and navigate to https://app.diagrams.net/.
  • A prompt asks where you want to save your diagrams. Click Device.

The editor loads with a shape library panel on the left and a blank canvas in the center. This confirms diagrams.net is ready to use.

Why choose Device?

Selecting Device saves your diagrams as .drawio files directly to your local machine. This keeps your artifacts alongside your other project files in the AAR_Legacy_Modernization folder instead of in a third-party cloud service.

Don't see the save location prompt?

If you've used diagrams.net before, it may remember your previous choice and skip the prompt. You can change it later by clicking the sun/moon icon or going to the menu.

If the page shows a loading spinner that never finishes, make sure JavaScript is enabled in your browser settings.

Help me get diagrams.net working in my browser.

Create your Project Context Summary document

Your first project document is the Project Context Summary. This is where you'll capture everything you learn about the client, the engagement, and the project scope in the next step.

  • Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
  • Type Word and press Enter to open Microsoft Word.
  • Click Blank document to create a new file.
  • Save the document immediately. Press Cmd+Shift+S (macOS) or Ctrl+Shift+S (Windows) to open the Save As dialog.
  • Navigate to your AAR_Legacy_Modernization/01_Project_Context folder on your Desktop.
  • Name the file Project_Context_Summary.docx and click Save.

Now set up a professional header at the top of the document. This is the first thing a project lead or client sees when they open your file.

  • At the top of your document, type the project name: AAR Legacy Integration Modernization and Operations Transformation.
  • On the next line, type Client: AAR Corp (NYSE: AIR).
  • On the next line, type Service Provider: Infosys Ltd.
  • On the next line, type Business Analyst: followed by your name.
  • Press Cmd+S (macOS) or Ctrl+S (Windows) to save.

Your document now has a clean professional header with the project name, client, service provider, and your role. Read it back. Could a project lead glance at this and immediately know which engagement, client, and analyst this document belongs to?

Why does the header matter?

On a consulting engagement, dozens of documents circulate between client and service provider teams. A consistent header on every artifact ensures that anyone who picks up your document knows exactly which project it belongs to and who authored it.

Can't find your folder in the Save As dialog?

Use the sidebar in the Save As dialog to navigate to Desktop, then open AAR_Legacy_Modernization, then 01_Project_Context. If the folder isn't on your Desktop, return to your terminal and re-run the ls command from earlier to check where it was created.

Help me save my Word document to the right folder.

Your workspace is organized and ready. You have a folder structure that mirrors how consulting firms work, a diagramming tool open for stakeholder mapping, and your first professional document saved. Next up, you'll read the project brief and build the context you need before talking to a single stakeholder.

Read the Project Brief and Build Context

Your workspace is organized and ready. Now it's time to do what every BA does on day one of a new engagement: read the project brief.

Your Infosys project lead has just handed you the Statement of Work for the AAR engagement. Before you talk to a single stakeholder, you need to understand the business, the engagement structure, and what success looks like. BAs who skip this step ask embarrassing questions in their first meeting. Questions the SOW already answers.

In this step, get ready to:
  • Read and internalize the simulated project brief for the AAR-Infosys engagement.
  • Write a Project Context Summary that translates the formal brief into a clear, BA-friendly document.
  • Identify at least 5 open questions the brief does not answer.
Read the simulated project brief

In a real consulting engagement, two documents govern how your firm works with the client. You need to understand both before you touch any deliverable.

What are MSA and SOW?

The Master Service Agreement (MSA) governs the overall relationship between AAR Corp and Infosys. It covers confidentiality, intellectual property, liability, and governance. Think of it as the umbrella contract.

The Statement of Work (SOW) defines this specific project's scope, deliverables, timeline, team structure, and acceptance criteria. As a junior BA, you work with the SOW day-to-day.

Below is the SOW excerpt your project lead has shared with you. This simulation is grounded in AAR Corp's real business operations, with the project scope expanded for learning purposes. Read through each section carefully.

Engagement overview

  • Project Name: AAR Legacy Integration Modernization and Operations Transformation.
  • Client: AAR Corp (NYSE: AIR), headquartered in Wood Dale, Illinois. AAR is a leading provider of aviation services to commercial and government operators, MROs, and OEMs, with operations in over 20 countries.
  • Service Provider: Infosys Ltd, a global leader in next-generation digital services and consulting.
  • Engagement Type: Fixed-price, 12-month delivery under existing MSA.

Client background

AAR Corp operates across three core segments: Parts, Repair and Engineering (including Airframe MRO and Component MRO), and Software (Trax). Trax is AAR's wholly-owned subsidiary and the premier provider of aviation maintenance mobile and cloud products in the global aviation market.

  • AAR recently acquired HAECO Americas, adding airframe MRO facilities in Greensboro, North Carolina and Lake City, Florida with immediate multi-year commitments from key customers.
  • AAR completed the expansion of its Oklahoma City facility, adding three heavy maintenance bays and approximately 200 roles in support of Alaska Airlines.
  • AAR initiated rollout of Paperless Hangar technology in Oklahoma City. Approximately 60% of legacy hangar capacity is now on paperless workflows. Greensboro is in early stages of implementation.
  • Trax products include eMRO (web-based MRO ERP), eMobility (suite of mobile apps for hangar-floor workflows), and Trax Cloud (hosting).

Project objectives

  • Modernize legacy MRO maintenance tracking systems across Oklahoma City, Greensboro, and Lake City facilities.
  • Migrate all facilities to Trax eMRO as the unified MRO platform.
  • Standardize maintenance operations across all facilities, including newly acquired HAECO Americas sites.
  • Deploy Trax eMobility suite for hangar-floor mobile workflows.
  • Establish standardized data flows and reporting across all facilities.

Scope: in-scope items

  • Current-state assessment of legacy systems at each facility.
  • Gap analysis between legacy workflows and Trax eMRO capabilities.
  • Process mapping (AS-IS and TO-BE) for maintenance operations.
  • Business requirements and functional requirements documentation (BRD and FRD).
  • Data migration planning from legacy systems to Trax eMRO.
  • Integration with Trax Cloud hosting infrastructure.
  • User training and change management.
  • UAT planning and execution, production cutover, and 30-day hypercare.

Scope: out-of-scope items

  • Parts Supply business segment operations.
  • Expeditionary Services operations.
  • Airvoyant AI procurement platform development.
  • Physical hardware or infrastructure upgrades at facilities.
  • Regulatory re-certification (maintained separately by AAR Compliance).
  • Component MRO operations at non-target facilities.

Team structure

AAR Corp side:

  • Project Sponsor: VP of MRO Operations.
  • AAR IT Lead: Director of IT Systems.
  • AAR MRO Operations Lead: Senior Director, Airframe Maintenance.
  • Facility Managers: one each for Oklahoma City, Greensboro, and Lake City.

Infosys side:

  • Engagement Manager: overall client relationship and commercial management.
  • Delivery Manager: day-to-day project execution.
  • Solution Architect: technical design and integration.
  • BA Lead: requirements management oversight.
  • Business Analyst (you): requirements gathering, process mapping, documentation.
  • QA Lead: testing strategy and UAT coordination.
  • Change Management Lead: training and adoption.

Key milestones

  • Project Initiation and Discovery (Weeks 1-4).
  • AS-IS Process Mapping and Gap Analysis (Weeks 5-10).
  • TO-BE Process Design and Requirements (Weeks 11-18).
  • Solution Design and Build (Weeks 19-32).
  • System Integration Testing (Weeks 33-38).
  • User Acceptance Testing (Weeks 39-44).
  • Production Cutover and Hypercare (Weeks 45-52).

Assumptions and constraints

Assumptions:

  • AAR will provide access to subject matter experts within 5 business days of request.
  • Existing Trax eMRO platform can accommodate AAR's airframe MRO workflows without major platform customization.
  • HAECO Americas facilities will adopt standardized Trax-based processes.
  • Legacy system data is available for migration assessment.
  • Infosys team will have on-site access to Oklahoma City and Greensboro facilities as needed.

Constraints:

  • 12-month project timeline with no extension option in the current SOW.
  • System integration must not disrupt active aircraft maintenance operations.
  • All process changes must maintain compliance with FAA maintenance regulations.
  • Budget is fixed-price per the MSA commercial terms.
  • Go-live must occur facility-by-facility, not as a big-bang cutover, to minimize operational risk.

Acceptance criteria

  • All deliverables reviewed and signed off by the AAR Project Sponsor.
  • All documented requirements traced to test cases.
  • UAT completion with zero critical defects.
  • Successful production cutover at each facility.
  • 30-day hypercare period with defined SLA metrics.

Read for patterns, not memorization

You do not need to memorize every detail. Focus on understanding the relationships: who is involved, what they care about, where the boundaries are, and what assumptions could break. These patterns are what you will use to build your summary and identify gaps.

Write your Project Context Summary

Reading the SOW is step one. Translating it into a document you can actually use is where the real BA work begins. A Project Context Summary distills the formal brief into clear, actionable sections that you can reference throughout the engagement.

  • Switch back to Project_Context_Summary.docx in Microsoft Word. Your professional header from Step 1 should still be at the top.
  • Below the header, add a section titled Client Overview. Write 2-3 sentences explaining who AAR Corp is, what they do, and why this project matters to their business. Include their core segments and the HAECO Americas acquisition context.
  • Add a section titled Project Objectives. Summarize the 5 project objectives from the SOW in your own words. Focus on what the project aims to achieve, not how it will get there.
  • Add a section titled Scope Summary. Split this into two parts: what is in scope (legacy system modernization, Trax eMRO integration, HAECO Americas standardization) and what is explicitly out of scope. Use your own phrasing.
  • Add a section titled Key Constraints and Assumptions. List the most impactful constraints (12-month timeline, no disruption to active maintenance, FAA compliance) and the assumptions that could break if reality does not match the SOW.
  • Add a section titled Engagement Structure. Describe how Infosys and AAR are organized for this project. Name the key roles on each side and explain who reports to whom.
  • Add a section titled Your Role. Describe what you as the BA are expected to deliver: requirements gathering, process mapping, and documentation. Note who you report to (the BA Lead) and who your key counterparts are on the AAR side.

Why write this in your own words?

Copy-pasting from the SOW proves you can use a clipboard. Writing in your own words proves you understand the project. When your project lead asks, "So, what's this engagement about?" you need to answer from understanding, not from memory.

If you struggle to rephrase a section, that is a signal you have not fully grasped it yet. Re-read that part of the brief and try again.

  • Save Project_Context_Summary.docx.
  • Scroll through your document. You should see the professional header from Step 1 followed by six clearly labeled sections: Client Overview, Project Objectives, Scope Summary, Key Constraints and Assumptions, Engagement Structure, and Your Role.

Feeling stuck on a section?

Scroll back up to the simulated project brief in this step and find the matching section. Each part of your summary maps directly to a section in the brief. If a section feels too thin, you may have missed a detail.

Help me figure out what to include in my Project Context Summary section.

Add your Open Questions section

Every SOW has gaps. Some are intentional (details left for discovery). Some are oversights. Part of your job as a BA is to find them before they surprise you in a meeting.

  • At the bottom of Project_Context_Summary.docx, add a new section titled Open Questions.
  • Re-read the SOW and your summary. For each section, ask yourself: "What does this NOT tell me that I would need to know before my first stakeholder meeting?"
  • Write at least 5 genuine gap questions. These should be things the SOW does not answer. For example: Who are the end-users at the HAECO Americas facilities? What legacy systems are currently in use at each site? What is the change management approach? What does AAR's compliance and audit cycle look like? What data currently flows between facilities?
  • For each question, add a brief note explaining why the answer matters to the project.

What makes a strong open question?

A strong open question is one where the answer would change how you approach the project. "What legacy systems are in use at each site?" is strong because the answer determines your data migration strategy.

A weak question is one the SOW already answers, or one that is too vague to act on. "What is the project about?" is weak because the SOW covers it. "Are there any risks?" is weak because it does not target a specific gap.

  • Save Project_Context_Summary.docx.

Now read your completed document from top to bottom. Ask yourself: could someone who has never seen the SOW understand the project's purpose, scope, and constraints from your summary alone? If any section feels vague, go back and add specifics from the brief.

Your finished document should have seven sections: Client Overview, Project Objectives, Scope Summary, Key Constraints and Assumptions, Engagement Structure, Your Role, and Open Questions with at least 5 gap questions.

You now have a solid grasp of the AAR engagement. Your Open Questions section is especially valuable. Those gaps become the seed for your meeting preparation in Step 4. But first, you need to figure out who matters on this project. In the next step, you will identify every stakeholder across AAR and Infosys and map exactly how much power and interest each one has.

Identify Stakeholders and Map Power/Interest

Your Project Context Summary gives you a solid understanding of what AAR needs and how the Infosys engagement is structured. Now it's time to figure out who matters.

The SOW names a handful of formal contacts. A project sponsor, a delivery lead, maybe a technical architect. But a real project has dozens of people who can influence success or quietly block progress.

If you miss a critical stakeholder now, you'll discover them later when they raise objections during UAT or after go-live. Your job is to find them before they find you.

In this step, get ready to:
  • Build a Stakeholder Register identifying 12-15 people across AAR and Infosys.
  • Create a Power/Interest grid in draw.io to visualize who needs your attention most.
  • Review and correct the grid when it reveals gaps in your stakeholder thinking.
Build the Stakeholder Register

A Stakeholder Register is the BA's master list of every person who can influence, approve, block, or benefit from the project. Building one forces you to think systematically about who matters, instead of relying on the few names the SOW happens to mention.

  • In Microsoft Word, create a new blank document.
  • Save it as Stakeholder_Register.docx in your 02_Stakeholder_Analysis folder.
  • Create a table with 8 columns. Label them exactly as follows:
  • Stakeholder Name/Role (the person's title or functional role).
  • Organization (AAR or Infosys).
  • Department (e.g., MRO Operations, IT, Finance, Quality).
  • Stakeholder Type (Decision Maker, Influencer, End User, or SME).
  • Interest in Project (a brief description of what this person cares about).
  • Influence Level (High, Medium, or Low).
  • Current Attitude (Supportive, Neutral, Resistant, or Unknown).
  • Preferred Engagement Approach (how you plan to interact with this person).

You should see a table with 8 column headers and empty rows ready to fill.

Why these 8 columns?

Each column captures a different dimension of stakeholder analysis. Stakeholder Type tells you their role in decisions. Current Attitude flags where you might face resistance.

Preferred Engagement Approach is the column most junior BAs skip. It forces you to think about how each person wants to be communicated with, not just whether they're important.

Start populating the register with stakeholders you can extract directly from the SOW. These are the formally named roles and contacts in the project brief.

  • Go through your Project Context Summary and the SOW. Add every named role or contact as a row in your table.
  • Fill in all 8 columns for each stakeholder. For Current Attitude, mark anyone you're uncertain about as Unknown. That's honest analysis, not a gap.

After adding SOW-named roles, you should have roughly 5-6 rows. This feels like progress, but it's a fraction of the people who will shape this project.

Now go beyond the SOW. Use AAR's business context to systematically identify the stakeholders that formal documents never mention. Work through each of these categories and add rows for every role you identify.

  • Who uses the legacy MRO systems today? Think about hangar floor supervisors, maintenance technicians, and parts procurement staff.
  • Who manages the Trax platform? Consider Trax system administrators and the IT infrastructure team who keep the systems running.
  • Who will be affected by process changes? Quality inspectors, compliance officers, and facility managers at the HAECO Americas sites all face workflow disruptions.
  • Who controls budget approval? AAR's finance lead and the Infosys Engagement Manager both hold financial authority.
  • Who has institutional knowledge? Long-tenured maintenance planners and shop floor leads know things that no document captures.
  • Who is on the Infosys delivery team? Add the Delivery Manager, Solution Architect, QA Lead, Change Management Lead, and your BA Lead.

Your register should now have 12-15 stakeholders spanning both organizations. Save Stakeholder_Register.docx.

Why go beyond the SOW?

SOWs are negotiated between senior leaders. They capture the people who signed the contract, not the people who will use the system every day. A maintenance technician at the Greensboro facility will never appear in a SOW, but they can make or break user adoption.

Struggling to reach 12 stakeholders?

If your register feels thin, go back to your Open Questions from the Project Context Summary. Each question implies a person who has the answer. "What legacy systems are in use at each site?" points to an IT lead at each facility.

help me identify stakeholders I might be missing for an MRO systems modernization project

Create the Power/Interest grid in draw.io

A flat register tells you who exists. A Power/Interest grid tells you who deserves your time. By plotting stakeholders on two axes, you force yourself to distinguish between a VP who can veto your requirements and a line technician who uses the system daily.

What is a Power/Interest grid?

A Power/Interest grid (also called Mendelow's Matrix) is a 2x2 matrix that classifies stakeholders along two dimensions. Power measures whether someone can stop the project or force a major decision. Interest measures whether someone is directly affected by or actively involved in the project.

The four quadrants each prescribe a different engagement strategy: Manage Closely (high power, high interest), Keep Satisfied (high power, low interest), Keep Informed (low power, high interest), and Monitor (low power, low interest).

  • Switch to the diagrams.net tab in your browser.
  • Delete any default shapes on the canvas so you start with a clean workspace.
  • Draw a large square or rectangle in the center of the canvas. Divide it into 4 equal quadrants using a vertical line and a horizontal line.
  • Label the X-axis Interest (Low on the left, High on the right).
  • Label the Y-axis Power (Low at the bottom, High at the top).
  • Label each quadrant: top-left Keep Satisfied, top-right Manage Closely, bottom-left Monitor, bottom-right Keep Informed.

You should see a clean 2x2 grid with labeled axes and four named quadrants. This is your canvas for stakeholder mapping.

Now plot every stakeholder from your register onto the grid. For each person, ask two questions.

  • For each stakeholder in your register, add a small text box or shape to the appropriate quadrant. Use their role title as the label.
  • To decide placement, ask: "Can this person stop the project or a major decision?" That determines their Power (Y-axis position).
  • Then ask: "Will this person be directly affected by or actively involved in the project?" That determines their Interest (X-axis position).
  • Color-code each shape by organization. Use one color for AAR stakeholders and a different color for Infosys stakeholders.

Color-coding in draw.io

Select a shape, then use the Format panel on the right to change its fill color. Pick distinct colors that are easy to tell apart at a glance. Blue for AAR and orange for Infosys works well.

Your grid should now show all 12-15 stakeholders plotted across the four quadrants, each color-coded by organization.

Review the grid and correct the gaps

Before you read the diagnostic patterns below, take a step back and look at your grid. Do your stakeholders spread across all four quadrants, or do most of them cluster in one or two areas?

Most first-time grids are lopsided. This is expected. The visual imbalance is the grid doing its job. It is exposing gaps in your stakeholder thinking that a flat register never would.

  • Check your grid against these diagnostic patterns:
  • If Manage Closely is empty or has only one name, you haven't identified the real decision-makers. The VP of MRO Operations, the AAR Project Sponsor, and the Infosys Engagement Manager all belong here.
  • If Monitor holds most of your names, you've listed people who won't meaningfully shape the project. Rethink whether they belong on the register at all.
  • If all AAR stakeholders cluster in a single quadrant, you haven't distinguished between a VP who can veto requirements and a line technician who uses the system daily. Their power levels are very different.
  • If Keep Informed is empty, you've likely missed the end users. Maintenance technicians and parts procurement staff have high interest (the new system changes their daily work) but low power (they can't stop the project).

Why is the grid lopsided?

SOWs are negotiated between senior leaders. They bias your initial thinking toward formal, high-power stakeholders. Operational stakeholders like hangar floor supervisors, quality inspectors, and facility managers at the HAECO Americas sites rarely appear in project contracts.

The grid's job is to surface this bias visually. A lopsided grid is a diagnostic signal, not a failure. The fix is to go back to your register and fill the gaps.

  • Return to your Stakeholder_Register.docx and add any stakeholders the grid revealed you were missing. Focus on the empty or thin quadrants.
  • Re-examine placements for any stakeholders whose power or interest level you may have misjudged. Adjust them on the grid.
  • Confirm that Manage Closely has at least 3-4 stakeholders. These are the people you'll prioritize in your meeting preparation.
  • Save your updated register in Word.
  • In draw.io, click File, then Save As.
  • Save the file as Stakeholder_Map.drawio in your 02_Stakeholder_Analysis folder.

Now read back your final grid. Your Stakeholder Register should have 12-15 stakeholders, and the grid should show stakeholders distributed across all four quadrants with at least 3-4 in Manage Closely. If the grid is still lopsided, go back to your register and keep enriching it until the distribution reflects reality.

Grid still looks unbalanced?

If you can't fill a quadrant, ask yourself: "Is there really nobody with that combination of power and interest?" For Keep Satisfied (high power, low interest), think about senior executives who signed off on budget but won't attend weekly meetings. AAR's finance lead is a classic example.

help me balance my Power/Interest grid for an MRO modernization project

You now know who matters on this project and exactly where each person sits on the power-interest spectrum. Next up, you'll turn that knowledge into a structured meeting preparation package that proves to your project lead you've done your homework before walking into a room with senior stakeholders.

Prepare for Your First Client Meeting

Your stakeholder register and Power/Interest grid give you a clear map of who matters on this project. Now you need to put that map to work by preparing for your first face-to-face conversation with those key stakeholders.

A poorly prepared BA walks in and says "tell me about your process," wasting 60 minutes of senior executives' time. You'll build a structured meeting preparation package that proves you've done your homework before entering the room.

In this step, get ready to:
  • Build a Know/Don't Know analysis that separates confirmed facts from open gaps.
  • Write a formal meeting agenda with specific objectives and the right attendees.
  • Prepare 8-10 open-ended discovery questions organized by theme.
Build a Know/Don't Know analysis

Before you can write an agenda or questions, you need to separate what the SOW already told you from what you still need to find out. A Know/Don't Know analysis is a two-column table that forces this separation.

  • In Microsoft Word, create a new blank document.
  • Save it as Meeting_Prep_Discovery_01.docx in your 03_Meeting_Notes folder.
  • Insert a two-column table.
  • Label the left column What We Know and the right column What We Don't Know.

Now fill both columns. Open your Project_Context_Summary.docx from the 01_Project_Context folder for reference.

  • In the What We Know column, list at least 5 facts confirmed by the SOW and your context summary.
  • Draw from: project objectives, scope boundaries, team structure, key milestones, AAR's business model, and the HAECO Americas acquisition details.
  • In the What We Don't Know column, pull from the Open Questions section of your context summary.
  • Add new gaps that surfaced during stakeholder identification in Step 3.
  • Aim for at least 5 items in this column as well.

What goes in the Don't Know column?

Think about the questions the SOW can't answer. What legacy systems does each facility actually use? What are the biggest pain points for maintenance technicians today?

How did the HAECO Americas acquisition change day-to-day operations? What does AAR's compliance and audit cycle look like? What data currently flows between facilities?

Each gap in this column becomes a reason your meeting exists. If you can't fill this column, you haven't looked hard enough at what you don't know.

  • Save Meeting_Prep_Discovery_01.docx.
  • Look at your two columns side by side. Every item in the What We Don't Know column should map to something you can ask about in the discovery session.

Struggling to fill the Don't Know column?

Go back to your Stakeholder_Register.docx. For each operational stakeholder (technicians, supervisors, procurement staff), ask yourself: "What would this person tell me that the SOW didn't cover?" That usually surfaces 3-5 new gaps.

If everything in both columns looks like it came from the same source, your Know column is probably too shallow. Re-read the SOW section on assumptions and constraints. Those often contain facts that are easy to overlook.

Help me think of gaps the SOW might not cover for the AAR modernization project.

Write the meeting agenda

Your What We Don't Know column just told you what the meeting needs to accomplish. Now you translate those gaps into a formal agenda that tells attendees exactly what to expect.

  • In Meeting_Prep_Discovery_01.docx, add a new section below your table titled Meeting Agenda.
  • Set the meeting title to "AAR Legacy Modernization - Discovery Session 1".
  • Add the date (today's date), duration (60 minutes), and location (Microsoft Teams).

Next, select the attendees. Your Power/Interest grid tells you exactly who needs to be in this room.

  • Switch to your Stakeholder_Map.drawio in the browser.
  • Identify 4-5 stakeholders from your Manage Closely quadrant (high power, high interest).
  • Back in your agenda document, list each attendee's name and role under an Attendees heading.

Why only Manage Closely stakeholders?

Discovery Session 1 is about validating scope and surfacing risks with people who have both the power to make decisions and a direct interest in the project's outcome. Inviting low-power stakeholders to this meeting dilutes the conversation.

You'll engage your Keep Informed and Keep Satisfied stakeholders through different channels later.

Now write the meeting objectives. Each objective should map directly to a gap in your What We Don't Know column.

  • Add a Meeting Objectives heading and write 3-4 specific objectives.
  • Example: Validate scope understanding with client stakeholders.
  • Example: Identify current-state pain points across MRO facilities.
  • Example: Surface risks and constraints not captured in the SOW.
  • Example: Understand stakeholder expectations for the Trax eMRO rollout.
  • Save Meeting_Prep_Discovery_01.docx.
  • Check that each objective traces back to at least one item in your What We Don't Know column. If an objective doesn't connect to a gap, it doesn't belong in this meeting.

Objectives feel too vague?

If your objective reads like "Discuss the project," it's not specific enough. A good objective names the information you need and why. Compare "Discuss current systems" with "Identify which legacy systems each facility uses and how data moves between them." The second version tells attendees exactly what to prepare.

Help me write sharper meeting objectives for a legacy system modernization discovery session.

Prepare your discovery questions

Your agenda tells attendees what the meeting covers. Your questions determine what you actually learn. Open-ended questions are the BA's primary tool in a discovery session.

Why open-ended over closed questions?

A closed question like "Do you use Trax?" gets a yes or no. An open-ended question like "Walk me through what happens when an aircraft comes in for heavy maintenance" gets stories, pain points, and information the SOW never captured.

Open-ended questions invite the stakeholder to share context you didn't know to ask about. That context is where the real requirements hide.

  • Below the agenda in Meeting_Prep_Discovery_01.docx, add a section titled Discovery Questions.
  • Organize your questions into four themes: Current State, Pain Points, Expectations, and Change Readiness.
  • Write 8-10 questions across these themes. Use the examples below as a starting point.

Example questions for each theme

Current State:

  • "Walk me through what happens when an aircraft comes in for heavy maintenance today, from induction to release."
  • "How do the Oklahoma City and Greensboro facilities differ in their maintenance workflows?"

Pain Points:

  • "Where do you lose the most time or data in your current process?"
  • "What workarounds has your team built to get around limitations in the current system?"

Expectations:

  • "What does success look like for your team six months after go-live?"
  • "What are you most concerned might go wrong?"

Change Readiness:

  • "How did your teams at the HAECO Americas sites react when they heard about the system change?"
  • For each question, add a brief note about what you expect to learn and why it matters.
  • Add your own questions beyond the examples to reach at least 8 total.
  • Save Meeting_Prep_Discovery_01.docx.

Make your notes work for you

The "what you expect to learn" note for each question serves two purposes. Before the meeting, it helps you stay focused on why you're asking. After the meeting, you can compare your expectations against what was actually said to spot assumptions you got wrong.

Questions sound too generic?

If your questions could apply to any IT modernization project, they need more specificity. Reference AAR's actual business context: name the facilities, name the systems, name the acquisition. "Tell me about your challenges" is generic. "How did the transition from your legacy system at Greensboro to the Trax platform affect your daily workflow?" is specific.

Help me make my discovery questions more specific to the AAR legacy modernization project.

Before you consider this step complete, ask yourself: could your project lead read this document and approve you to run the session?

  • Open Meeting_Prep_Discovery_01.docx and review it from top to bottom.
  • Confirm your Know/Don't Know table has at least 5 items in each column.
  • Confirm your agenda has a title, date, duration, location, 4-5 named attendees with roles, and 3-4 specific objectives.
  • Confirm you have 8-10 open-ended questions organized by theme, each with a note on expected learning.

Your preparation package is ready. Next up, you'll put it to the test in a simulated discovery session where stakeholders reveal things the SOW missed. Then you'll document everything in a formal MOM and build a RACI matrix.

Run the Discovery Session, Write Your MOM, and Build RACI

In the last step, you built a professional meeting preparation package. You have a Know/Don't Know analysis, a formal agenda, and targeted discovery questions. Your project lead would approve you to walk into the room.

Now you validate everything with real people. The discovery session is where you confirm your understanding and uncover what the SOW deliberately left out. But the session itself is only half the job. The Minutes of Meeting is a contractual record that everyone agreed on what was discussed, decided, and who owns what. The RACI matrix then translates your stakeholder knowledge into a clear accountability structure. Without it, two people think they own the same deliverable. Or nobody does. Both kill projects.

In this step, get ready to:
  • Simulate your first discovery session and document three critical revelations the SOW missed.
  • Write a formal Minutes of Meeting (MOM) with action items, owners, and due dates.
  • Build a RACI matrix that assigns clear accountability for every key project deliverable.
Simulate the discovery session

Discovery sessions exist to surface information that formal documents miss. A well-prepared BA walks in with targeted questions, but the real skill is handling what comes back unexpectedly.

In this simulation, you will read through a scenario where senior AAR stakeholders reveal critical information that your SOW does not capture. Your job is to document each revelation, assess its impact, and determine what action to take.

  • Open your Meeting_Prep_Discovery_01.docx from the 03_Meeting_Notes folder so your prepared questions are visible alongside the scenario.

Read through the following scenario carefully. Imagine you are sitting in the Microsoft Teams call with your prepared agenda in front of you.

Discovery Session 1: What the stakeholders reveal

You are 30 minutes into your first discovery session. The attendees are the stakeholders you selected from your "Manage Closely" quadrant. AAR's VP of MRO Operations has been answering your current-state questions when they pause and raise three issues.

Revelation 1 (Database mismatch): "The legacy system at Oklahoma City runs on a completely different database than what Greensboro uses. When we acquired HAECO Americas, we inherited their system as-is. The SOW talks about migrating to Trax like it's one migration, but you're really looking at two separate data sources with different schemas, different field mappings, and different data quality levels. That's a much bigger lift than what's scoped."

Revelation 2 (Change resistance): "The maintenance technicians at the Greensboro and Lake City facilities have used their current system for over 15 years. They know every workaround, every shortcut. When we mentioned Trax at the last town hall, the reaction was... not warm. You need a plan for these folks, or they'll find ways to work around the new system and you'll have two parallel processes running."

Revelation 3 (Regulatory deadline): "There's something else that isn't in the SOW. We have a regulatory audit scheduled for Q1 next year. The auditors will want to see that our maintenance records are traceable and consistent across all facilities. If we're mid-migration when that audit hits, we need a very clear story about data integrity. This creates a hard deadline the project hasn't accounted for."

  • Create a new section at the bottom of your Meeting_Prep_Discovery_01.docx called "Discovery Session Notes."
  • For each of the three revelations, document four things: what was said, why it matters to the project, what action you need to take, and who should own that action.
  • Note which of your prepared discovery questions surfaced each revelation. Did any of them come up without you asking?
  • Save your file.

Why trace revelations back to your questions?

This exercise connects meeting preparation to meeting outcomes. If your "Current State" questions surfaced Revelation 1, your preparation worked. If Revelation 3 came up unprompted, that tells you the stakeholder had an urgent concern the SOW completely missed.

Professional BAs track this connection because it improves their question design for future sessions. Over time, you learn which types of questions consistently surface hidden risks.

Review your discovery notes. Each revelation should have a clear "so what" and a clear "now what." If any entry just restates what the VP said without analyzing the impact, go back and add your analysis.

Write your formal MOM

Your discovery notes captured what happened in the session. Now you need to turn those raw notes into a formal Minutes of Meeting. The MOM is not a transcript. It is a contractual record that everyone in the meeting can sign off on.

  • Create a new Word document called MOM_Discovery_Session_01.docx in your 03_Meeting_Notes folder.
  • Add the MOM header: project name ("AAR Legacy Integration Modernization and Operations Transformation"), meeting title ("Discovery Session 1"), date, time, and location (Microsoft Teams).
  • Add an Attendees section listing each person's name and role. Mark anyone absent.

Save the file and confirm you can see the header and attendees looking clean and professional. This is the section stakeholders will check first when you circulate the MOM.

  • Add an "Agenda Items Discussed" section listing numbered agenda items from your meeting prep.
  • Add a "Discussion Summary" section organized by agenda item. Capture the key points and different perspectives raised. This is where you weave in the substance of what was discussed, not just the revelations.

Summarize, don't transcribe

A common junior BA mistake is writing the MOM like a transcript ("Then John said... then Sarah replied..."). Instead, capture the substance: the insight, the concern, the data point. Attribute statements only when the speaker's authority matters ("The VP confirmed that...").

  • Add a "Decisions Made" section. State each decision as a clear commitment, not a vague intention. Write "The team agreed to conduct separate data audits for OKC and Greensboro before migration planning begins" instead of "The team discussed doing data audits."
  • Add an "Action Items" section as a table with four columns: Action Item, Owner, Due Date, and Status.

Save and review your action items table. Every single row must have an owner name and a specific due date. "TBD" in the Owner column means nobody owns it. "ASAP" in the Due Date column means it will never get done.

What makes a good action item?

A good action item is specific, assigned, and time-bound. Compare: "Look into the database issue" (vague) vs. "BA to document the database schema differences between OKC and Greensboro legacy systems by [date]" (actionable). The second version tells the reader exactly what will be done, by whom, and by when.

  • Add a "Risks/Issues Raised" section. Document the three revelations from the discovery session as formal risks. For each, write the risk description, its potential impact on the project, and a proposed mitigation approach.
  • Add a "Next Steps" section that answers: what happens after this meeting, and when is the next session scheduled?
  • Save MOM_Discovery_Session_01.docx.

Now review your MOM against your original meeting objectives from Step 4. Open your Meeting_Prep_Discovery_01.docx and compare the objectives you set with what the session actually achieved. Note which objectives were met and which remain open for follow-up sessions.

MOM feels too short or too long?

A good MOM for a 60-minute session is typically 2-3 pages. If yours is under a page, you have likely listed actions without capturing the reasoning behind decisions. If it is over 4 pages, you are probably transcribing instead of summarizing.

Help me review my MOM structure and make it more professional.

Build your RACI matrix

You now know who the stakeholders are, how they relate to each other, and what the project deliverables look like. The RACI matrix translates all of that knowledge into a single accountability map.

What is a RACI matrix?

RACI stands for four roles. R (Responsible) means you do the work. A (Accountable) means you own the outcome and give final approval. C (Consulted) means you provide input before the work is done. I (Informed) means you are told after a decision is made.

The critical rule: every deliverable must have exactly one "A." Two people accountable means nobody is accountable.

  • Create a new Word document called RACI_Matrix.docx in your 02_Stakeholder_Analysis folder.
  • Create a table. The rows are key project deliverables. Add these nine rows: Project Context Summary, Stakeholder Register, AS-IS Process Maps, BRD, FRD, Requirements Traceability Matrix (RTM), UAT Test Cases, Production Cutover Plan, Post Go-Live KPI Report.
  • The columns are stakeholder roles. Add these eight columns: BA (you), BA Lead, Delivery Manager, Solution Architect, AAR Project Sponsor, AAR MRO Operations Lead, AAR IT Lead, Infosys Engagement Manager.

Save and check that your table has 9 rows and 8 columns. This is the structure you will fill in next.

  • For each cell, assign one letter: R, A, C, or I. Think about each deliverable carefully. For example, you (the BA) are likely R for the Stakeholder Register, but your BA Lead is A because they own the quality of your output.
  • Enforce the one-A rule. Count the A's in each row. If any row has zero or more than one A, fix it before moving on.
  • Check for overload. If one role has R in every single row, the work is unrealistically concentrated on that person. Redistribute where it makes sense.
  • Check for misplaced accountability. The AAR Project Sponsor should be A for strategic deliverables like the Production Cutover Plan, not for operational deliverables like UAT Test Cases. If you have confused strategic and operational accountability, adjust your assignments.
  • Save RACI_Matrix.docx.

What does a well-balanced RACI look like?

The Infosys delivery team (BA, BA Lead, Delivery Manager, Solution Architect) should carry most of the R assignments because they do the hands-on work. AAR stakeholders appear mainly as A (for deliverables they approve) and C (for deliverables that need their input).

The Infosys Engagement Manager typically appears as A for overall delivery milestones and I for detailed artifacts. They own the client relationship, not the individual documents.

Struggling with R vs. A assignments?

The difference between R and A trips up most junior BAs. Ask yourself: "Who does the work?" (that's R). "Who gets fired if the deliverable is wrong?" (that's A). The person who does the work and the person who is accountable for the outcome are often different people.

Help me figure out my RACI assignments.

Review your artifacts against quality criteria

Before you check your work, think about this: if you handed your MOM to someone who was not in the meeting, could they understand exactly what happened, what was decided, and who owns what next? That is the bar.

  • Open MOM_Discovery_Session_01.docx and check three things. First: does every action item have an owner AND a due date? Second: are decisions stated as clear commitments, not vague intentions? Third: are all three revelations documented in the Risks/Issues Raised section with impact and mitigation?
  • Open RACI_Matrix.docx and verify that every deliverable row has exactly one A. Count them.

You should see a complete MOM that reads like a professional record, not a set of personal notes. Your RACI matrix should have 9 deliverable rows, 8 role columns, and a clear accountability chain with no gaps.

Why this review matters

In a real engagement, your BA Lead will review these artifacts before they go to the client. A MOM with missing owners gets sent back. A RACI with two A's in the same row gets questioned. Building the habit of self-review now saves you that feedback loop later.

Secret mission

Build a Stakeholder Communication Plan

You've identified who matters, mapped their power and interest, and assigned accountability with RACI. But analysis without action is just paperwork. Can you design a communication plan that gives every stakeholder group exactly the right information, at the right time, through the right channel?

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely on your local machine using Microsoft Word and diagrams.net in the browser, so there are no ongoing costs or cloud resources to worry about.

Decide whether to keep your project artifacts for the next project in the series, close things down temporarily, or delete everything.

Resources you used:

  • AAR_Legacy_Modernization folder on your Desktop, containing 7 documents across 4 subfolders (.docx and .drawio files).
  • diagrams.net browser tab (no account created, no data stored online).

Keep everything running

No action needed. Choose this if you plan to continue with the next project in the AAR-Infosys BA Simulation Series.

  • Keep your AAR_Legacy_Modernization folder where it is. Project 2 (AS-IS/TO-BE process mapping) builds directly on the artifacts you created here.
  • Your Stakeholder Register, Power/Interest grid, MOM, and RACI matrix are all referenced in future projects.
  • Keep your diagrams.net browser tab open if you want to revisit your Stakeholder Map.

Pause - I'll come back to this later

Close your open applications to free up memory. Your files are saved locally and will be there when you return.

  • Save and close all open Word documents (Project_Context_Summary.docx, Stakeholder_Register.docx, MOM_Discovery_Session_01.docx, and any others you have open).
  • Close your diagrams.net browser tab. Your Stakeholder_Map.drawio file is saved locally in your 02_Stakeholder_Analysis folder.
  • Your entire AAR_Legacy_Modernization folder stays on your Desktop. When you return, just reopen the files you need.

Delete - I don't want to use this again

Remove all project files from your machine. This deletes every document you created in this project.

  • Close any open Word documents and the diagrams.net browser tab first.
  • Delete the entire AAR_Legacy_Modernization folder from your Desktop.

On macOS, open Terminal and run:

rm -rf ~/Desktop/AAR_Legacy_Modernization

On Windows, open PowerShell and run:

Remove-Item -Recurse -Force ~\Desktop\AAR_Legacy_Modernization

You can also right-click the AAR_Legacy_Modernization folder on your Desktop and select Move to Trash (macOS) or Delete (Windows).

No accounts or cloud data to remove

This project did not create any online accounts or store any data in the cloud. diagrams.net was used without an account, so there is nothing to delete on their end.

Nice Work!

Nice Work!

Nice work! You've just completed the full project initiation cycle for the AAR Legacy Modernization engagement.

You've learned how to:

  • Built a Project Context Summary from a formal project brief, capturing the client's business drivers, scope boundaries, and the gaps a BA must fill before their first stakeholder meeting.
  • Created a Stakeholder Register with 12+ stakeholders across both client and service provider teams. Mapped them on a Power/Interest grid to prioritize engagement, going beyond formal contacts to find the operational people who can influence the project.
  • Ran a discovery session that surfaced information the SOW missed and documented it in a formal MOM with action items, owners, and due dates. Built a RACI matrix assigning clear accountability for every key project deliverable.
  • Secret Mission: Built a Stakeholder Communication Plan that turns your stakeholder analysis into an ongoing plan for how, when, and what you communicate to each group throughout the project.

Ready to quiz yourself?