IS Tech Application Resistance to change

 Is necessary  Competition, consumers, technology demand ▪ Better, more perfect products/services ▪ Lower costs/prices ▪ Faster execution, delivery, recovery

 Is necessary  Competition, consumers, technology demand ▪ Better, more perfect products/services ▪ Lower costs/prices ▪ Faster execution, delivery, recovery  But painful  People have to change ▪ the way they do their jobs ▪ the things and people whom they trust ▪ The way they are evaluated

 Safety sensitivity….lives and licenses at stake  Immense Complexity  Every part on every component on every air craft must be tracked, inspected, scheduled for service  Air craft almost constantly in motion (getting the right part to the right place at the right time)  Supply chain includes hundreds of vendors and contractors  Financial survival requires reliability

 Illustrated parts catalogue  A list of every part and component on the a/c  Schedule of how many hours/flights/cycles of various “time controlled” parts  Inventory of spare parts …. By serial number, location, bin including parts “out on repair” at a repair vendor  Supply chain ordering system with contract terms, order history for “contracted parts”

 Maintenance  Routine inspections, servicing, unscheduled hoc frame repair  Repair  Removal, servicing, replacement of componenets  Overhaul  Major/”Heavy” maintenance (taking the plane apart and re-assembling every few years)

 Approved repair manuals  Company generated  Vendor manuals  Work cards  Electronic sign-off

 New development efforts harder to justify then maintenance of existing systems/programs  Cost of failure is extra-ordinarily high  Only the operating people know what they really need,  Hard to remove from the operation to do planning  They usually want to automate the current process…..which usually sub-optimizes  They think they “know” and often minimize the importance of training  Want to revert to “the way we used to do it” when ever there is a problem

 Demonstrate status quo is not viable

 Demand broad involvement in design, test and implementation planning

 Demonstrate status quo is not viable  Demand broad involvement in design, test and implementation planning  Do a slice at a time whenever possible

 Demonstrate status quo is not viable  Demand broad involvement in design, test and implementation planning  Do a slice at a time whenever possible  Have credible experts on tap to help

 Demonstrate status quo is not viable  Demand broad involvement in design, test and implementation planning  Do a slice at a time whenever possible  Have credible experts on tap to help  Celebrate accomplishments and build ownership (“our system” vs “the system”)

 Who should run development projects; operators or IT people?  How do you gain commitment?  Bonuses? Joint accountability? Emotional identification/pride?  Why a slice at a time?  How do you test whether a vendor can delivery?  How do you avoid unnecessary “customization”?