Module 10 - Applied Business Case Exercises for OFA 1

• 1.Requirements Management and Analysis
• 2.Operational and Technical Support

Scenario Context

The learner is asked to help catalog, under the direction of the OFA leading the migration, what data exists in the old spreadsheets before migration planning begins.

Task

• 3.Review a sample of legacy spreadsheets from three wards.
• 4.Document what fields are used and how consistently they are used across wards.
• 5.Note where data is missing, duplicated, or contradictory.

Required Output

• 6.A data inventory note listing the fields found, consistency issues between wards, and specific records that look incomplete or duplicated.
• 7.The note should be written so the migration lead can use it to plan field mapping without re-opening the raw spreadsheets.

• 1.Strong Performance Indicators
• a.Flags inconsistent formats, such as dates entered differently from ward to ward
• b.Identifies likely duplicate or orphaned records without fixing them unilaterally
• c.The note is organized well enough that the lead can act on it directly
• 2.Weak Performance Indicators
• a.Silently "cleans up" data without flagging that anything was changed
• b.Misses obvious duplicate entries
• c.Blends findings with the OFA's own edits without labeling which is which

• 1.The following is a simplified excerpt from a field mapping table a more senior OFA might eventually produce, building on an inventory note like the one above:
• 2.Notice that every legacy column has an explicit outcome, including the one that is intentionally not migrated, with a stated reason.
• 3.This is the standard of thoroughness a good data inventory note should be aiming toward: nothing simply disappears without a documented decision.

• 1.At OFA 2, the same migration expands into full ownership
• 2.Specific Responsibilities

• 3.Defining the field mapping between old and new systems
• 4.Engaging the ward clerk to resolve ambiguity and inconsistent field usage
• 5.Producing a migration plan dividing automatic steps from manual re‑entry

Business Case 2·Mobile App Feature - Activity RSVP in a Youth Activities App

Scenario

A mobile app used for local unit youth activities is adding a feature that lets youth RSVP to stake activities and receive reminders.

• 1.Requirements Management and Analysis.
• 2.Operational and Technical Support.

Scenario Context

The learner is asked to gather reactions to a proposed RSVP screen from a small group of ward youth leaders, under the direction of the OFA leading the feature.

Task

• 3.Run short, structured feedback conversations with three youth leaders using prepared open questions.
• 4.Document their reactions, clearly separating what a leader explicitly said from the learner's own interpretation.

Required Output

A feedback synthesis note grouped by theme (usability, missing capability, unrelated concerns), ready for the feature lead to review.

• 1.Strong Performance Indicators
• a.Feedback is grouped by theme, not presented as a chronological quote dump.
• b.Factual feedback is separated from the learner's impressions.
• c.Any leader who described a fundamentally different need is flagged rather than folded in as if it matched.
• 2.Weak Performance Indicators
• a.Feedback is a raw quote list with no synthesis.
• b.Unrelated complaints about other parts of the app are mixed in without being flagged as out of scope.

An excerpt from a requirements document that a senior OFA might build from feedback synthesis notes like the one above:

• 1.Example 1 — Maximum Capacity
• a.# Requirement·The system must allow a youth leader to set a maximum capacity for an activity at the time it is created.
• b.# Rationale·Stake leadership stated that several past activities were over-subscribed relative to venue capacity, creating a safety and logistics concern.
• c.# Priority·Must Have (MoSCoW)
• 2.Example 2 — Capacity Warning
• a.# Requirement·The system should notify a leader when an activity reaches 90 percent of its stated capacity.
• b.# Rationale·Leaders requested advance warning to arrange more space.
• c.# Priority·Should Have (MoSCoW)
• 3.Example 3 — Remaining Spots Visibility
• a.# Requirement·The system could allow youth to see how many spots remain before RSVPing.
• b.# Rationale·Several youth leaders suggested this would reduce last-minute cancellations, but it was not a stated need from stake leadership.
• c.# Priority·Could Have (MoSCoW)

Notice each requirement includes both a rationale tracing back to a real stakeholder statement and an explicit priority category - which is exactly why a good feedback synthesis note separates fact from interpretation so clearly.

• 1.At OFA 2, the same RSVP feature becomes an owned requirements workstream.
• 2.Specific Responsibilities

• 3.Facilitating a requirements session with stake youth leadership to define capacity limits, waitlists, and reminder timing.
• 4.Independently triaging early crash reports from the pilot before deciding whether to escalate.

Business Case 3·Website Platform Change - Event Pages to a New Platform

Scenario

The organization is retiring an older website platform used for stake and temple event pages in favor of a new content platform.

• 1.Requirements Management and Analysis
• 2.Operational and Technical Support

Scenario Context

The learner is asked to catalog existing content on five sample stake sites before migration, under the direction of the migration lead.

Task

• 3.Review each site's pages and note which content is current versus stale (past event dates, broken links, outdated contact information).
• 4.Recommend keep or retire for each page, with reasoning.

Required Output

A content inventory listing each page, a recommendation, and the reasoning behind it.

• 1.Strong Performance Indicators
• a.Obviously stale content is correctly flagged.
• b.Ambiguous cases go to the lead for a decision rather than resolved unilaterally.
• c.Every page listed was actually opened and checked, not judged by title alone.
• 2.Weak Performance Indicators
• a.Keep or retire decisions are made on personal opinion of what seems "unnecessary" without verifying.
• b.Broken links are missed because pages were skimmed rather than opened.

A content inventory like the one above eventually feeds a redirect mapping like this:

/events/2025-youth-conference       -> /events/archive  (expired event, redirect to archive) /events/2026-stake-conference       -> /events/2026-stake-conference  (current, unchanged) /contact/old-form                   -> /contact  (form replaced by new unified contact page) /leadership/former-stake-presidency -> [no redirect - retiring, agreed with stake communication specialist 2026-05-12]

• 1./events/2025-youth-conference -\> /events/archive (expired event, redirect to archive) /events/2026-stake-conference -\> /events/2026-stake-conference (current, unchanged) /contact/old-form -\> /contact (form replaced by new unified contact page) /leadership/former-stake-presidency -\> [no redirect - retiring, agreed with stake communication specialist 2026-05-12]

• 2.Every retired path has an explicit destination, or an explicit, dated, attributed decision not to redirect it.
• 3.This is the same completeness standard a good content inventory should be building toward.

• 1.At OFA 2, the same platform migration becomes an owned workstream.
• 2.Specific Responsibilities

• 3.Facilitating a call with local content owners to confirm keep-or-retire decisions
• 4.Building the full redirect mapping
• 5.Producing a go-live checklist with a post-launch verification step

Business Case 4·CRM Change - Replacing a Legacy Volunteer Contact Tool

Scenario

A department is replacing an aging tool used to track volunteer coordinator contacts and outreach with a modern relationship management system.

• 1.Requirements Management and Analysis
• 2.Operational and Technical Support

Scenario Context

The learner supports validation of a sample of migrated records against the old system.

Task

• 3.Compare a sample of records field by field between the old and new systems.
• 4.Record any mismatches factually, without assuming the cause.

Required Output

A test execution record comparing each sampled field, with mismatches flagged.

• 1.Strong Performance Indicators
• a.Every field in the sample is checked methodically, not just visible ones.
• b.Subtle issues such as truncated phone numbers or misassigned roles are caught.
• c.Discrepancies are reported as observations, not as assumed causes.
• 2.Weak Performance Indicators
• a.Only obvious fields like name are spot-checked.
• b.The learner states an assumed cause for a discrepancy as if it were confirmed.

• 1.Field-by-field checks are eventually formalized into validation rules such as these:
• a.Every migrated record must have a primary contact method (email or phone).
• b.No two migrated records may share both the same name and the same phone number, which would indicate an unresolved duplicate.
• c.Every volunteer's assigned role must match one of the roles defined in the new system's role list.
• d.Unmatched roles must be flagged for manual review, not dropped silently.

Each rule is specific enough to be checked mechanically against the migrated data, which is what separates a testable validation rule from a vague goal such as "the data should look right."

• 1.At OFA 2, the same CRM replacement becomes an owned workstream.
• 2.Specific Responsibilities

• 3.Defining specific, testable validation rules for the migration
• 4.Facilitating a user acceptance session with volunteer coordinators

Triaging a post-launch report of duplicate outreach messages

• 1.Requirements Management and Analysis
• 2.Operational and Technical Support

Scenario Context

The learner gathers input on what the deep link needs to carry by interviewing app support staff who field related calls today.

Task

• 3.Document the pain points members currently report.
• 4.Separate the literal complaint from the underlying need.
• 5.Note what data the link would need to carry (member identifier, appointment identifier, temple).

Required Output

A pain point and requirement note

• 1.Strong Performance Indicators
• a.A literal complaint such as "I didn't know what to click" is correctly connected to the underlying need for the notification to land on the right screen.
• b.The note identifies the specific data needed to construct the link.
• 2.Weak Performance Indicators
• a.The note lists complaints generically without connecting them to what data or capability is actually required.

Pain point notes like the one above eventually inform a data contract such as this:

Parameter: appointmentId (required) - uniquely identifies            the appointment Parameter: memberId (required) - uniquely identifies the            member for authentication Parameter: templeId (optional) - used only for display;            defaults to the member's most recently used            temple if omitted Fallback behavior: if appointmentId cannot be matched to an                   active appointment, the app opens to the                   member's appointment list screen rather                    than showing an error.

• 1.Parameter·appointmentId (required) - uniquely identifies the appointment Parameter: memberId (required) - uniquely identifies the member for authentication Parameter: templeId (optional) - used only for display; defaults to the member's most recently used temple if omitted Fallback behavior: if appointmentId cannot be matched to an active appointment, the app opens to the member's appointment list screen rather than showing an error.

• 2.The explicit fallback behavior is the detail most often missing from a first attempt at this kind of documentation.
• 3.This is exactly the level of specificity a strong pain point and requirement note should be working toward.

• 1.At OFA 2, the same deep-linking effort becomes an owned workstream.
• 2.Specific Responsibilities

• 3.Facilitating agreement between the notifications and app teams on the link's exact data contract.
• 4.Triaging "not found" errors for specific appointment types during testing.

• 1.Requirements Management and Analysis
• 2.Operational and Technical Support

Scenario Context

The learner documents the current manual reservation process before integration requirements are written.

Task

• 3.Interview two facility schedulers about how they reserve rooms today and produce an as-is process description.
• 4.Note any manual verification step schedulers currently rely on to avoid conflicts.

Required Output

An as-is process note for someone unfamiliar with the process so they can recreate it

• 1.Strong Performance Indicators
• a.The manual double-check step is explicitly identified and explained, since it points to the exact failure mode the integration must not reintroduce.
• b.The process description is specific rather than general.
• 2.Weak Performance Indicators
• a.The process is described too generally to be actionable.
• b.The manual workaround schedulers rely on today is missed entirely.

• 1.An as-is process note eventually supports a requirement such as this:
• a.Requirement·The system must detect a room-booking conflict and reject the conflicting booking within 5 seconds of submission.
• b.Rationale·A nightly sync was evaluated and rejected because it would leave up to a 24-hour window in which two units could book the same room without either being aware of the conflict, which directly caused a double-booking incident during a prior pilot.

• 2.This requirement, with its timing threshold and a stated rationale tied to a failure mode, is the standard of specificity this kind of documentation should be held to.
• 3.This is in contrast to a vaguer statement such as "the systems should stay in sync."

• 1.At OFA 2, the same integration becomes an owned workstream.
• 2.Specific Responsibilities

• 3.Facilitating agreement between the reservation and calendar teams on how conflicts will be detected - real-time versus nightly sync.
• 4.Triaging a real double-booking incident during the pilot.

• 1.Requirements Management and Analysis
• 2.Operational and Technical Support

Scenario Context

The learner documents current pain points with the manual phone-tree process by interviewing two ward callers.

Task

• 3.Identify what specifically goes wrong with the manual process today (missed calls, outdated numbers, inconsistent timing).
• 4.Separate what callers explicitly describe from the learner's own inference.

Required Output

A pain point note ready for the notification system's requirements lead

• 1.Strong Performance Indicators
• a.Pain points are specific and traceable to what a caller actually said.
• b.The note distinguishes a technology problem (no way to send bulk messages) from a data problem (contact list is out of date).
• 2.Weak Performance Indicators
• a.Pain points are generic ("the old way is inefficient") without specific detail.
• b.A data problem and a technology problem are treated as the same issue.

A pain point note like the one above eventually informs a requirement such as this:

• 1.Requirement 1·A family must be able to opt out of activity reminder notifications by replying "STOP" to any text message or by selecting a one-tap opt-out link in any email reminder.
• 2.Requirement 2·Opting out must take effect before the next reminder is sent.
• 3.Rationale·Stake leadership and ward callers agreed that requiring a family to call the ward office to opt out, as under the manual process, was itself a barrier that discouraged families from opting out even when they wanted to.

Specifying both the mechanism and the timing requirement is what separates this from a vague statement such as "families should be able to opt out."

• 1.At OFA 2, the same rollout becomes an owned workstream.
• 2.Specific Responsibilities

• 3.Facilitating a discussion with ward leadership to define reminder timing and opt-out mechanics precisely.
• 4.Triaging a pilot report of duplicate reminders before escalating.

• 1.Requirements Management and Analysis
• 2.Operational and Technical Support

Scenario Context

The learner catalogs what each of the three source systems currently reports and how, under the direction of the dashboard project lead.

Task

• 3.For each source system, document what attendance-related data it holds and how it is currently extracted (manual export, existing report, direct access).
• 4.Note any obvious differences in how the same concept is defined across systems.

Required Output

A source inventory note ready for the lead to use in scoping the dashboard

• 1.Strong Performance Indicators
• a.Differences in how "attendance" is defined across systems are explicitly flagged, since this is the most common hidden problem in a multi-source reporting effort.
• b.The note distinguishes confirmed facts about each system from the assumptions.
• 2.Weak Performance Indicators
• a.All systems are assumed to define attendance the same way without checking.
• b.The inventory only lists system names without describing what data each holds.

A source inventory note supports an agreed definition. For example, for dashboard purposes, "attended" means a member was checked in through any of the three source systems for at least 50 percent of a given activity's scheduled duration.

• 1.Source System Adjustments:
• a.System A already records duration and requires no change.
• b.System B only records a binary checked-in or not, and will be treated as "attended" for the full duration whenever checked in, which is a known simplification to be revisited if it proves misleading.
• c.System C records multiple check-in events per activity and will use the sum of all recorded durations.

Stating the definition precisely, and naming System B's simplification as a known, intentional limitation rather than an oversight, is what a strong source inventory note should be building toward.

• 1.At OFA 2, the same dashboard effort becomes an owned workstream.
• 2.Specific Responsibilities

• 3.Facilitating a discussion among representatives of all three source systems to agree on a single, shared definition of "attendance."
• 4.Documenting what each source system must adjust to match it.