Why I’m sharing this
If you’ve ever supported an operational team during peak season, you know that delays are rarely caused by a lack of effort. More often, they come from the way the work is stitched together—handoffs, system timing, and “small” dependencies that quietly stop progress. I saw that firsthand in international student services, where a delayed Form I-20 can ripple into missed visa appointments, deferred enrollment, and a stressful student experience.
This article is a practical case study from my work modernizing financial document collection and I-20 issuance for undergraduate international students at a public university. I’m focusing on the business analysis decisions behind the change: how we uncovered hidden dependencies, clarified ownership, designed for exceptions, and built reporting into the workflow instead of around it.
The situation we started with
Before redesign, the workflow depended on multiple systems and a lot of manual coordination. The team did the right things, but the process itself made “waiting” the default.
What the day-to-day looked like
- Staff queried admission data and maintained spreadsheets to track admitted students and I-20 progress.
- Students uploaded financial documents in the admissions system, and staff relied on reports to identify submissions—reports that could lag or miss edge cases.
- Visa-related data (such as program dates) was updated in the student information system, creating a timing dependency before records could sync into the immigration workflow tool.
- Profiles were created one student at a time and were sensitive to small data mismatches (for example, incorrect program dates).
- Graduate Assistants downloaded documents from one system and re-uploaded them into another, then updated status in spreadsheets and Teams messages.
- Once an I-20 was issued, staff downloaded the document and manually emailed it to the student, then updated the spreadsheet again.
Hidden bottlenecks (the ones that didn’t show up on the surface)
When we mapped the process end-to-end, two “silent blockers” stood out.
1) System synchronization as a built-in waiting period
Even when staff completed their tasks quickly, they still had to wait for data to synchronize across systems. That dependency added time without adding value—and it was hard to explain to stakeholders because nothing looked “wrong,” it just wasn’t ready yet.
2) A student action that gated profile creation
A second dependency was tied to student behavior: profile creation required students to complete an intent-to-enroll step in the admissions system. When students missed it (often unintentionally), the workflow stalled. The student didn’t know they had blocked anything, and staff often didn’t have immediate visibility into why the case wasn’t moving.
What I did as the BA
The biggest shift was treating the delays as a design problem instead of a performance problem. That framed the work around removing constraints—not adding more checks.
Techniques that made the difference
- End-to-end process modeling and value stream analysis to separate compliance requirements from legacy habits.
- Root cause analysis to name the actual dependencies driving delays (system timing, student-action gates, and manual handoffs).
- Stakeholder mapping and role clarification to define who owns decisions, exceptions, and handoffs across departments.
- Requirements definition and traceability across integrated systems so configuration and reporting aligned to the desired outcomes.
- Scenario-based testing (including edge cases) and permission checks before rollout.
Design principles we used to guide decisions
Rather than debating every step from scratch, we used a small set of principles that made trade-offs easier and kept the redesign consistent.
- Decouple progress from non-essential student actions wherever possible.
- Reduce document re-handling (aim for single-touch checks instead of repeated downloads/uploads).
- Make status and ownership explicit (a case should never be “stuck” without a clear reason and owner).
- Embed reporting in the workflow so visibility doesn’t depend on a separate spreadsheet.
- Design for peak volume and exceptions, not just the “happy path.”
What changed in the redesigned workflow
The redesigned approach centered on collecting and reviewing documents directly within the immigration workflow environment and building resilience into intake and profile creation.
New workflow at a glance
- Admitted students appear automatically in the workflow environment, reducing reliance on delayed reports and manual spreadsheet updates.
- Profiles are created in bulk to reduce one-by-one administrative setup and to better support high-volume processing.
- Profile creation is no longer blocked by intent-to-enroll confirmation, allowing work to proceed even when students miss an administrative step.
- Students upload documents directly into the workflow environment where they are immediately available for review.
- Graduate Assistants perform a single-touch completeness check and route cases for DSO review using standardized statuses.
- DSOs issue I-20s in-system, triggering notifications and preserving audit-ready case history.
- Built-in reporting replaces spreadsheet tracking and provides real-time operational visibility.
From spreadsheets to operational visibility
In the old process, reporting was a separate activity: staff reconciled spreadsheets and messages to figure out what was happening. In the redesigned workflow, reporting became part of operations. Leaders could see admitted volume, status counts, and stalled cases without manual updates.
That visibility changed management behavior. Instead of discovering bottlenecks after deadlines, supervisors could spot them early, balance workloads, and intervene where a case truly needed attention. It also strengthened audit readiness because status histories and timelines were captured within the workflow itself.
Results and impact
The outcomes were measurable and felt immediately by the team.
- System-driven waiting periods were eliminated as a primary delay driver.
- I-20 readiness moved to near real-time once documents were complete and reviewed.
- Manual document re-uploads were eliminated, reducing handling effort and error risk.
- Graduate Assistant handling steps dropped by more than half through single-touch checks and clearer routing.
- Spreadsheet-based tracking was replaced with real-time queries and embedded analytics.
- Process stalls caused by intent-to-enroll gating were removed.
Lessons learned (what I’d do again)
- Map the process the way people actually work, not the way the policy document describes it—workarounds often explain most delays.
- Treat waiting time as a first-class problem. Cycle time is usually dominated by queues, synchronization, and handoffs.
- Define ownership boundaries and request statuses early. Automation works best when everyone agrees what “in progress” and “ready” mean.
- Design for the missed-student-step scenario. If a workflow can stall silently, it eventually will—especially at scale.
- Build reporting into the process. If leaders need a spreadsheet to understand reality, the process is already brittle.
Reusable artifacts (practical takeaways)
If you want to apply this approach to other workflows, these artifacts are a good starting point:
- A single-page value stream map showing handoffs, queues, and decision points (with waiting time highlighted).
- A dependency log listing “gates” (system timing, upstream approvals, student actions) and the design strategy for each.
- A status model that defines each request status, owner, exit criteria, and the exception path.
- A test scenario pack that includes edge cases (missing student steps, data mismatches, high-volume bursts).
- A lightweight reporting spec: the top 5 operational questions leadership needs answered daily.
Closing
This project reinforced a simple idea: faster processing doesn’t usually come from pushing people harder. It comes from removing the hidden dependencies that make good work wait on things the team can’t see or control. When you design for visibility and resilience, speed tends to follow.
Author: Adwoa Arhin, Business Analyst, University of North Carolina at Greensboro
Adwoa Arhin is a Business Analyst in the Global Engagement Office at the University of North Carolina at Greensboro, supporting International Student and Scholar Services (ISSS) through workflow improvement and digital transformation initiatives, including efforts to streamline I-20 processing. She is PMP certified, an IIBA member, and has prior experience as a CRM Business Analyst in the telecommunications sector.