implementing administrative systems? you need an evolution, not a revolution! university of...
TRANSCRIPT
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
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
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
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
Linda Nelson
Gary Prohaska
Paul Schurr
Jelena Curless [email protected]
Erick Winger