04 / Academic project · Graduate team project · Systems proposal
Airline Disruption Management
Our team proposed a platform to help an airline respond to operational disruptions. I focused on the constraints that would affect implementation, including stakeholders, contracts, timing, and dependencies.
University of Washington · Enterprise Information Systems Analysis and Design
Project at a glance
- Project type
- Academic coursework · Graduate team project · Systems proposal
- My role
- Feasibility analysis and current-state presentation material.
- Objective
- Assess a proposed platform for coordinating airline disruptions.
- Key deliverables
- Legal and stakeholder considerations, schedule/resource analysis, and input to the team baseline plan.
- Tools / methods
- Systems analysis, process flows, stakeholder assessment, dependency planning.
- Outcome / status
- Academic systems proposal; not deployed or operationally validated.
The problem
Weather, maintenance, staffing, and system disruptions can require decisions across many airline teams. The project explored how better information sharing and decision support could help coordinate the response.
My contribution
My assigned feasibility sections addressed legal and contractual considerations, organizational and stakeholder constraints, and schedule and resource planning. I also prepared current-state presentation material. The overall system design and final proposal were team work.
The work
- Examined the relationships between operational teams and supporting systems.
- Identified stakeholders and contractual considerations affecting implementation.
- Considered how rollout timing and dependencies could create operational risk.
- Contributed to a baseline plan for evaluating a phased implementation.
How the solution took shape
Describe the current state
I prepared presentation material showing the types of disruption an airline responds to and the people affected. The current-state analysis highlighted manual coordination and systems that did not share information effectively.
Trace the coordination needs
The analysis connected external events to airline operations, flight and ground teams, customers, and external stakeholders. This helped show why an isolated technical feature would not address the full operational problem.
Examine implementation constraints
My assigned feasibility sections considered legal and contractual issues, organizational and stakeholder concerns, and schedule and resource needs. I identified areas such as crew constraints, passenger commitments, training, and cross-team coordination that the proposed implementation would need to address.
Consider the effect on stakeholders
I discussed how automation could affect multiple organizations and why security and trust would matter to adoption. These were considerations for the academic proposal, not findings from a regulator or an operational approval process.
Connect dependencies to rollout timing
I explained why implementation activities would need a defined sequence and participation from the right teams. A peak travel period was one example of timing that could increase rollout risk and would need careful evaluation.
Support a phased proposal
The team baseline plan proposed a pilot before a wider rollout, with an 18-month network deployment target. My contribution explained the constraints that would need to be resolved as the implementation plan developed; the team did not deploy or validate the platform.
A closer look
Why disruption response needs coordination
Weather · Maintenance · Staffing · IT issues
Airline operational decisions
Information and decisions need to move across teams and systems.
Flight & ground teams
Coordinate crews, arrivals, and gate changes.
Customers
Receive updates about delays and travel changes.
External stakeholders
Provide information and coordinate the wider response.
Actual project artifacts
Samples from the project
The finished coursework brought the current-state analysis, proposed future state, recommendations, and feasibility assessment into a final team report. My contribution focused on current-state presentation material and the legal, stakeholder, and scheduling constraints. The future-state diagram below shows the team’s proposed solution.
Original slide showing how weather and public-health disruptions affect operational teams, customers, and external stakeholders. Academic current-state analysis, not an implemented platform.
View full size
The proposed workflow connects disruption detection to early warnings, recovery recommendations, staff approval, operational changes, passenger updates, and post-event feedback. This is the proposed design, not a deployed airline system.
View full size
Original slide from the team’s final report covering scheduling, legal constraints, and stakeholder acceptance. It documents the proposed phased rollout and human review safeguards. The 18-month timeline was a planning assumption, not a completed implementation.
View full sizeAn example from the work
An implementation consideration
A rollout during a peak travel period could create additional risk. The plan needed to account for operational timing, stakeholder readiness, and dependencies before proposing a wider implementation.
The project in numbers
Proposal target
18 monthsProposed network rollout horizon
The baseline plan proposed a phased rollout after a pilot. The team did not implement the platform or verify operational savings.
What came out of it
The team delivered a proposed platform and baseline project plan. My contribution kept attention on implementation constraints and the coordination required before introducing a new system into a complex operation.
This project shows how I assess the environment around a solution before treating implementation as a scheduling exercise.
Project scope and limits
Academic systems proposal, not an airline deployment or commissioned engagement. Performance benefits and regulatory approval were not established.