BA Academy — self-paced module
By the end of this module, you will be able to:
This module covers the two artifacts that bracket a well-run project: the teaming agreement written at the start (how we will work together) and the lessons learned process at milestones and the end (what we learned from working together). Both are simple, neither is glamorous, and teams that use them consistently outperform teams that rely on good intentions. As a BA, you will often be the person who drafts the first and facilitates the second.
A teaming agreement is a document outlining expectations and requirements for all project team members, with a focus on communication and collaboration tools, norms, and ground rules. It provides a high-level description of the project and its objectives, plus team member roles and responsibilities.
Think of it as the project team's operating manual, written by the team, for the team, before the pressure starts. It ensures alignment and cooperation throughout the project, and its benefits are concrete:
You met the lightweight cousin of this idea in Module 16 (team agreements as a relationship practice). The teaming agreement is the full, project-grade version.
Below is the full structure, section by section. To make it concrete, we will build a running fictional example around WellCare Solutions, the fictional HealthTech company from Module 4, kicking off its Salesforce implementation with a fictional consulting team.
A snapshot anyone can absorb in a minute: project name, internal project codes, high-level scope, a link to the SOW, brief background, and duration.
Example (fictional): Project: WellCare CRM Implementation. Scope: lead management, renewal alerts, reporting for leadership. Background: sales tracked in spreadsheets; renewals being missed; leadership lacks pipeline visibility. Duration: eight months, June through January. SOW: linked in the project repository.
What the project must achieve, in plain language, including how workstreams relate: especially where multiple teams or vendors work in parallel. If another team is running a concurrent project with adjacent scope, say so explicitly, name the crossover areas, and state how the teams will align on solution design. Nothing generates friction like two teams discovering mid-project that they both think they own duplicate management.
Example (fictional): Objective 1: define and address gaps in lead and renewal processes via discovery, then three build-test-deploy sprints with stabilization time and train-the-trainer per sprint. Objective 2: deliver documentation so WellCare can sustain the environment after handoff. Objective 3: coordinate weekly with WellCare's internal IT team, which is concurrently upgrading email integration: crossover is heaviest in data quality rules, so solution designs in that area get joint review.
For every team member: name, role, location and time zone, allocation (hours per week), start and end dates on the project, and core responsibilities. This section kills two chronic problems: nobody knowing who owns what (Module 16's RASIC, in prose), and nobody realizing a key resource is only allocated ten hours a week until they are shocked by the response time.
Example (fictional): Project Manager: Keala M., Hawaii (HST), 10 hours/week, full duration. Leads planning, execution, monitoring, and closure; owns the project plan, risk mitigation, and scope adherence; bridges the delivery team, client, and any partner teams. Solution Architect: Jordan T., Texas (CST), 40 hours/week, full duration. Technical lead; owns overall technical design; go-to for architects, developers, and BAs; ensures workstreams adhere to design and scope. Business Analyst: Nalani K., Hawaii (HST), 30 hours/week, full duration. Leads discovery and requirements; owns user stories, acceptance criteria, RTM, UAT coordination, and training materials.
State the delivery approach explicitly, because teams assume differently. Many real projects are hybrids, and writing the hybrid down prevents methodology arguments later.
Example (fictional): Hybrid approach: requirements definition and release planning are completed up front (plan-driven), then defined stories and acceptance criteria are developed in three-week Agile sprints (Module 10's machinery). Timeline: discovery in months one and two; three sprints across months three through six; UAT, training, and go-live in months seven and eight.
Everything a new team member needs on day one: system and tool access (time tracking, client collaboration spaces, email, Salesforce, the work-item tracker), links to background materials (proposal, SOW, sales-to-delivery handoff, deliverables from prior phases, client-provided process docs and org charts), and kickoff next steps with owners and dates ("all team members read the linked background materials by the 15th and confirm completion").
The heart of the agreement. Two halves:
The tool map. Which tool is used for what, with links: time tracking here, internal collaboration and documents there, task tracking and the RTM in this tool, the RAID log in that one, work items and sprints in the tracker, this platform for internal meetings, that one when the client requests it. (Exact tools vary by firm: Module 10's advice stands: the map matters more than the brands.)
The norms: specific, dated, and owned. Vague norms ("communicate proactively") are decoration. Real norms look like:
Example (fictional): All team members log time by the last working day of each week. All team members record planned leave in the shared out-of-office sheet, block their calendars, and update their forecast. Anyone marked Responsible for a task in the project plan updates its status and percent complete by end of day Thursday. The weekly status report goes to WellCare every Friday, owned by the project coordinator, with the PM as backup in their absence.
Notice what those norms have in common: a verb, an owner, and a deadline. If a norm has no deadline and no owner, it is a hope.
Clear definitions for tickets and general use of the tracking tool: what counts as an epic, feature, story, task, issue, or bug on this project (Module 4's hierarchy, localized), what fields are mandatory, and what the workflow states mean. Firms and even projects differ; writing the local dialect down saves every future argument about whether something is "really a bug."
Every recurring meeting, documented with: the meeting name exactly as it appears in the calendar invite (so people can actually find it), the owner, the intention (why the meeting exists and what it covers), time and duration, required and optional attendees, and any special expectations.
Example (fictional): Delivery Team Standup. Owner: Jordan T. Intention: status, upcoming work, and blockers; Jordan relays updates gathered in the separate developer standup. Time: 30 minutes daily, 10:00 AM HST. Required: Jordan, Nalani, Keala, plus the development leads. Optional: the account lead. Anyone who cannot attend must check in asynchronously via a channel post before the meeting.
The intention line is the quiet hero: meetings whose purpose is written down can be evaluated, shortened, or retired. Meetings without stated intentions live forever on inertia (recall Module 16's meeting craft).
How work gets sequenced and assigned: for example, at the discovery-to-build checkpoint, the solution architect and BA work with the technical architects and PM to plan the order in which user stories will be developed; the development team assesses stories and estimates level of effort; backlog rank, dependencies, and assignments are recorded in the tracker; and changes to the project plan are owned by the PM. Everyone knows the machine's moving parts and who turns which crank.
Where issues and roadblocks are reported and tracked (the tracker), and who collaborates to resolve them (PM, architects, BAs, and relevant members, in the tool, so the resolution trail survives). This is the RAID discipline from Module 10 given a home address.
Where deliverables and milestones are defined and tracked (the project plan), and the standard that every user story carries clear acceptance criteria in the tracker (Module 4, enforced by agreement).
Where risks and mitigation strategies live (the RAID log), and the review cadence ("risk assessments are reviewed in steering committee meetings every other week and the log updated"). A risk log without a scheduled review is a diary, not a control.
Team members explicitly agree to maintain the confidentiality of project-related information and adhere to data security protocols. On projects involving regulated data (health, financial: recall Modules 2 and 7), this section may reference specific compliance obligations. It reads as boilerplate until the day it is not; make everyone read it anyway.
The agreement is reviewed at the close of each milestone and amended to reflect project changes and improvements. A teaming agreement is a living document: teams change, tools change, and norms that seemed right in month one get revised by month four's reality.
Four recommended sections transform the document from logistics into leadership. Most teams skip them. Do not.
Each member answers: What are your personal goals for this project, and what do you hope to gain or learn?
Examples (fictional): "I want to gain confidence in my presentation skills and would like to be assigned to lead end-user training." "I am working toward a promotion to manager and want opportunities to gain experience developing others."
The practice: members complete this in advance, speak to it in the kickoff meeting, and the team uses it to create real opportunities within the project. A team that knows Nalani wants training experience assigns her the training lead, and everyone wins: the project gets an invested trainer, and Nalani gets her growth. Careers are built one deliberate assignment at a time, and this section is where assignments become deliberate.
Each member answers: What challenges or gaps do you foresee, and where do you need support?
Examples (fictional): "This is my first nonprofit-sector project and I am not familiar with the domain." "The background materials indicate heavy custom code, but the bulk of my experience is with declarative features."
Completed in advance, spoken to in the meeting, and used to arrange support early or reevaluate assignments. This section only works in psychological safety (Module 16's trust practices): a team where admitting a gap is punished will fill this section with fiction, then discover the gaps in production.
Communication and collaboration preferences, stated plainly so teammates can work with each other instead of around each other.
Example (fictional): "I think meetings should have agendas communicated in advance so we avoid unnecessary ones. I start my day at 9 AM HST and prefer meetings no earlier than 9:30, with exceptions as needed. I block calendar time for heads-down work; please ask before booking over a hold."
On distributed teams spanning time zones (which is to say, on your future teams), this section prevents a hundred small collisions.
The team's shared behavioral commitments, drafted collectively: each member lists personal values important for teamwork, the team identifies themes that resonate, drafts principles, and refines to consensus.
Example (fictional): "We treat each other with mutual respect and assume best intentions. We commit to asking for help and offering it. When we raise a concern, risk, or issue, we propose a solution alongside it. We acknowledge that everyone has bad days, and we avoid toxic behaviors: blaming, finger-pointing, condescension, rudeness. We have each other's backs. We hold ourselves and each other accountable to these principles."
Always include that final accountability sentence: principles without mutual accountability are wall art. Reference your organization's own stated values where they exist, and make the principles specific enough to invoke ("remember, we propose solutions with concerns") in a real moment of friction.
Lessons learned is the process of identifying key challenges and opportunities and uncovering actionable insights from projects, engaging all team members in problem-solving discussions that drive continuous improvement. It is the project-scale sibling of the sprint retrospective (Module 10), and the formal close-out practice Module 14's transition phase hands off to.
Why capture them:
The classification is what turns a pile of anecdotes into an analyzable asset: six months later, someone can ask "what do our last four projects teach us about UAT?" and actually get an answer.
Lessons-learned sessions touch real mistakes made by real people in the room, so the facilitator (often you) sets ground rules first:
Notice how much this resembles the retrospective craft from Module 10 and the facilitation skills of Module 20: same muscles, project-sized weight. And notice the deeper prerequisite: people only surface honest lessons in psychological safety. The trust you built with Module 16's practices, and the blame-free tone you set with these ground rules, decide whether your lessons-learned log contains truth or theater.
At project start, the BA is frequently the teaming agreement's drafter and keeper: you run the kickoff exercise, collect the human sections, and own the document's upkeep at milestone reviews. At project end (and at milestones along the way), the BA is frequently the lessons-learned facilitator: you keep the log, theme the entries, run the session by the ground rules, and chase the assigned actions. Both roles fit you for the same reason training did in Module 13: you carry the project's context, you write clearly, and you facilitate well. Volunteer for both, every time: they are visible, valuable, and they compound your reputation as the person who makes teams work.
8 questions. Answer at your own pace, then check the explanation for each.
Nice work. Review any question again using the menu (top right), or move on.
Continue to Module 18: Career Growth & Certification Pathway →