1. Implementing Administrative Systems? You need an Evolution, not a Revolution! UNIVERSITY OF WASHINGTON Copyright [your name] [year]. This work is the intellectual property of the author. Permission is granted for this material to be shared for non- commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.

2. Jeanne Marie Isola, Director, Strategic Initiatives Office Linda Nelson, Administrator, Department of Physics Gary Prohaska, Technology Manager Paul Schurr, Senior Systems Engineer Jelena Curless – Senior Systems Engineer Erick Winger – FDI Customer Service Lead UNIVERSITY OF WASHINGTON Public Research University Three Campus Sites 41,089 Student Enrollment 23,462 Faculty and Staff Two medical centers and a School of Medicine #1 public university in federal support for research and training

3. Agenda I. Overview - Jeanne Marie Isola II. End User Perspective - Linda Nelson III. Technology Manager’s Perspective - Gary Prohaska IV. Usability Perspective - Jelena Curless V. Developer’s Perspective - Paul Schurr VI. Customer Support Perspective - Erick Winger

4. Evolution? Revolution?

5. Involvement The USER approach to creating administrative systems USER Teams Iterative Approach! *Executive Vice President, Vice Provost for Research, Vice Provost for Planning and Budgeting, Vice President for Computing & Communications **e.g., Financial Management, Planning and Budgeting, Human Resources, Computing & Communications Meeting user needs! Engaging University Users!

7. SPONSO R EVP* PROJECT MANAGERS SIO Manager Technical Manager VOLUNTEERS Process Improvement Teams User Task Groups Testers APPLICATION USERS Feedback Sessions; Surveys; Focus Groups *Executive Vice President Customer Driven!

8. STEP 1: Prepare and Define Scope STEP 2: Envision and Whiteboard STEP 3: Design Prototype STEP 4: Working Prototype STEP 5: Test and Implement STEP 6: Measure and Monitor Iterative A Six Step Process

9. Significant time commitment Opportunity to contribute to institution-wide endeavor Gain understanding of institutional structure and processes Sense of accomplishment Volunteers’ Experiences

10. ev.o.lu.tion A gradual process in which something changes into a different and usually more complex or better form The process of developing Software Evolution

11. Intensely collaborative design with end-users, central office experts, and technical developers Massively iterative; change is relentless Evolutionary; no mistakes Visual Agile; lightweight More Art than Science Strong executive sponsorship and IT governance The USER Approach to software development

13. The Usability Perspective Usability is not a science - the typical answer to any question is: “it depends” Requires considering many perspectives You won’t get it right by yourself, with your development team, or just talking to business experts You won’t get it right the first time

14. The Usability Perspective Off-the-shelf products reflect the development company’s priorities not our business language someone else’s tradeoffs Developing own products takes time, but you get it right the first time teams include business specialists, end users, and technical specialists (so you can make good tradeoffs) well thought-out - tradeoffs are made in advance, communicated to all, feedback is invited

15. The Usability Perspective Iterative approach works well: opportunity to refine the design insert testing using the visual aids developed along the way Expand feedback to broader audience each time you develop a set of ever more detailed visuals

16. USER Projects are Different from Traditional IT Projects

17. no spec, vague scope

18. USER Projects are Different from Traditional IT Projects no spec, vague scope frustrating and rewarding

19. USER Projects are Different from Traditional IT Projects no spec, vague scope frustrating and rewarding sometimes it’s the only way to get it right

20. Developing with a User Task Group provide research and technical feedback

21. Developing with a User Task Group provide research and technical feedback provide mock-ups and prototypes

22. Developing with a User Task Group provide research and technical feedback provide mock-ups and prototypes create flexible architecture, expect change

23. Developing with a User Task Group provide research and technical feedback provide mock-ups and prototypes create flexible architecture, expect change enjoy the help

24. Customer Support Involvement Change Management: those on the frontline of change understand why Customer Support has credibility/knowledge Gain understanding of system limitations and processing Communication with campus prior to rollout Helping Hand for developers: Customer Support can manage broad testing representation Facilitate creation of testing groups Create testing scripts Manage testing groups and filter feedback

25. Customer Support Involvement Being involved in building process and testing assists the Customer Support team in creating: Triage Structure Rollout: training key-items FAQs Understanding of user types HELP pages, web documentation http://ucs.admin.washington.edu/MyFD/Home.aspx

26. Questions? Jeanne Marie Isola jmisola@u.washington.edu Linda Nelson lrn@phys.washington.edu Gary Prohaska gpro@cac.washington.edu Paul Schurr pschurr@u.washington.edu Jelena Curless jelena@u.washington.edu Erick Winger erickw@u.washington.edu