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.

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

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

Evolution?

Revolution?

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!

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!

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

Significant time commitmentOpportunity to contribute to

institution-wide endeavorGain understanding of institutional

structure and processes Sense of accomplishment

Volunteers’ Experiences

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

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

Whiteboarding(visioning; lots of yakking)

Visio(non-working prototype)

HTML(just another pretty face)

ArchitectureStubs

(some navigation andfunctionality)

WorkingPrototype

STOP(start over)

BuildProduct

USERPRODUCT

LIFECYCLE

GO!

Product Release

Dead end

Dead end

Dead end

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

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

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

USER Projects are Different from Traditional IT Projects

USER Projects are Different from Traditional IT Projects

no spec, vague scope

USER Projects are Different from Traditional IT Projects

no spec, vague scope

frustrating and rewarding

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

Developing with a User Task Group

provide research and technical feedback

Developing with a User Task Group

provide research and technical feedback

provide mock-ups and prototypes

Developing with a User Task Group

provide research and technical feedback

provide mock-ups and prototypes

create flexible architecture, expect change

Developing with a User Task Group

provide research and technical feedback

provide mock-ups and prototypes

create flexible architecture, expect change

enjoy the help

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

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

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