Educause_042406_FINAL

26
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.

Transcript of Educause_042406_FINAL

Page 1: Educause_042406_FINAL

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.

Page 2: Educause_042406_FINAL

Jeanne Marie Isola, Director, Strategic Initiatives OfficeLinda Nelson, Administrator, Department of Physics

Gary Prohaska, Technology ManagerPaul Schurr, Senior Systems Engineer

Jelena Curless – Senior Systems EngineerErick Winger – FDI Customer Service Lead

UNIVERSITY OF WASHINGTON Public Research University

Three Campus Sites 41,089 Student Enrollment

23,462 Faculty and StaffTwo medical centers and a School of Medicine

#1 public university in federal support for research and training

Page 3: Educause_042406_FINAL

AgendaI. 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

Page 4: Educause_042406_FINAL

Evolution?

Revolution?

Page 5: Educause_042406_FINAL

InvolvementThe 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!

Page 6: Educause_042406_FINAL
Page 7: Educause_042406_FINAL

SPONSOR

EVP*

PROJECT MANAGERSSIO Manager

Technical Manager

VOLUNTEERSProcess Improvement Teams

User Task Groups Testers

APPLICATION USERS Feedback Sessions; Surveys; Focus

Groups

*Executive Vice President

Customer Driven!

Page 8: Educause_042406_FINAL

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

IterativeA Six Step Process

Page 9: Educause_042406_FINAL

Significant time commitmentOpportunity to contribute to

institution-wide endeavorGain understanding of institutional

structure and processes Sense of accomplishment

Volunteers’ Experiences

Page 10: Educause_042406_FINAL

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

Page 11: Educause_042406_FINAL

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

Page 12: Educause_042406_FINAL

Whiteboarding(visioning; lots of yakking)

Visio(non-working prototype)

HTML(just another pretty face)

ArchitectureStubs

(some navigation andfunctionality)

WorkingPrototype

STOP(start over)

BuildProduct

USERPRODUCTLIFECYCLE

GO!

Product Release

Dead end

Dead end

Dead end

Page 13: Educause_042406_FINAL

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

Page 14: Educause_042406_FINAL

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

Page 15: Educause_042406_FINAL

The Usability PerspectiveIterative 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

Page 16: Educause_042406_FINAL

USER Projects are Different from Traditional IT Projects

Page 17: Educause_042406_FINAL

USER Projects are Different from Traditional IT Projects

no spec, vague scope

Page 18: Educause_042406_FINAL

USER Projects are Different from Traditional IT Projects

no spec, vague scope

frustrating and rewarding

Page 19: Educause_042406_FINAL

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

Page 20: Educause_042406_FINAL

Developing with a User Task Group

provide research and technical feedback

Page 21: Educause_042406_FINAL

Developing with a User Task Group

provide research and technical feedback

provide mock-ups and prototypes

Page 22: Educause_042406_FINAL

Developing with a User Task Group

provide research and technical feedback

provide mock-ups and prototypes

create flexible architecture, expect change

Page 23: Educause_042406_FINAL

Developing with a User Task Group

provide research and technical feedback

provide mock-ups and prototypes

create flexible architecture, expect change

enjoy the help

Page 24: Educause_042406_FINAL

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

Page 25: Educause_042406_FINAL

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