![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.](https://image.slidesharecdn.com/743fac3d-b5a2-49c7-a6d8-9c3861aacbc1-151104223036-lva1-app6892/85/Educause_042406_FINAL-1-320.jpg)
Recommended
More Related Content
What's hot
What's hot (12)
Similar to Educause_042406_FINAL
Similar to Educause_042406_FINAL (20)
Educause_042406_FINAL
- 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
- 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 IterativeA 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. USER Projects are Different from Traditional IT Projects 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
Editor's Notes
- GREETINGS MY NAME IS JEANNE MARIE ISOLA EXCITED TO BE HERE TODAY! SHARE WITH YOU A UNIQUELY SUCCESSFUL METHOD OF INCORPORATING CHANGE MANAGEMENT AND CONTINUOUS PROCESS IMPROVEMENT INTO THE PROCESS OF IMPLEMENTING NEW ADMINISTRATIVE SYSTEMS SOFTWARE
- INTRODUCE PERSPECTIVES AND INTRODUCE uw – CHECK ON FACTS FIRST – LET ME TELL YOU A LITTLE BIT ABOUT EACH OF US AND THE INSTITUTION WE REPRESENT – THE UNIVERSITY OF WASHINGTON I AM JOINED WITH MY COLLEGUES LINDA NELSON, AN ADMINISTRATOR OF PHYSICS…… AND, GARY PROHASKA…. MY BACKGROUND IS…..
- “Evolution” vs. “Revolution” What comes to mind? When Implementing Administrative Systems? Who here has been involved with implementing Administrative Systems? Who here has been involved in implementing Enterprise Resource Planning Systems (e.g. PeopleSoft, Oracle, SAP) How would you characterize your experience? An evolution? A revolution? Why?
- Engaging University community Employees Sponsors* USER Steering Committee User Task Group Process Improvement Teams Business Stewards** Outcomes Old systems automated Web tools for Users Streamlined business practices Culture of change
- TALK ABOUT ROLE OF SIO – PROVIDING NEUTRALITY
- Good morning, my name is Linda Nelson and I’m going to speak about the USER method from a users standpoint. I’ve worked at the UW for 18 years and experienced significant changes to the administrative systems whose purpose was to benefit the end user. The intent was excellent and the execution much less so. What makes USER different? First, it is customer drive. Points to make: Users have an opportunity to share input through out process, while technical staff is ‘on the job’ the other folks are volunteering time away from primary (paying) jobs. Project Management takes care of upper level details (planning meetings, working across groups) to let team members concentrate on application. Managers report to Sponsor who serves as an advocate (but doesn’t run the show)
- Process is Iterative. Points to make: PITs prepare groundwork and define scope. UTGs do the work of creating application. UTGs include developers, users and customer service staff.
- Volunteering – a time commitment. Reporting UTG meet 2 hrs a week weekly for 18 months (or was in 20??). Volunteers find it very rewarding as outlined above.
- Hi, my name is Gary Prohaska. I’ve worked at the UW for 25 years in the central IT organization. My current role is Technology Manager responsible for enterprise level development projects, including Financial Desktop and the other web applications like Employee Self-Service you saw in a previous slide. But not all of our development projects use the “USER Approach”. Some are much more traditional in nature, due in part to IT staff who have either not been exposed to the USER Approach or who remain skeptical that forgoing reams of detailed requirements documentation can actually yield a better product. Traditional methodology is more like a revolution. You have several meetings with the “clients”, draft the requirements document, get them to sign it and start construction. When you’re done building you get back together to find out if you built the right thing. The word EVOLUTION defines the USER Approach. A highly iterative process which starts with a set of high level requirements and evolves into very sophisticated software thru constant collaboration involving much trial and error.
- 1. all the right people working on the same problem at the same time for a long time; the UTG is not where you take something to show people for their consent; it’s a place you come away from with requirements for the next iteration 2. rapid cycles; not much time between iterations 3. ideas get transformed into software; relies upon trial and error and discovery. All dead ends are natural consequences of evolution; not mistakes. Traditional methodology relies upon contractual scope and detailed specifications prior to building. “You can’t start building until you know what to build.” USER says that in a complex, heterogeneous environment like a research university, “you can’t know EXACTLY what to build until you start building it” --- i.e. discovery and evolution 4. emphasis on visual models and usability. Usability is the most important consideration. If no one uses your incredibly well-engineered software, what good is it? 5. more emphasis on feedback than on extensive documentation; low level of initial technical commitment makes it easier to adapt to change 6. Sometimes there is a naïve belief that technical products are mysteriously complex because of the technology, whereas, as most of you have experienced first hand, most of the mystery and complexity comes from us being human, acting irrationally and belonging to campus organizations that are even more mysterious and irrational. No wonder codifying business rules is more art than science or engineering. The USER Approach embraces that notion and takes the time to get it right, acknowledging that trial and error is often a cost-effective strategy. 7. essential for any successful project
- Here’s the Jester Hat slide depiction of the USER methodology. We start with what people see. The plumbing comes later. Lots of low cost modeling with increasing bits of functionality. Constant feedback and iteration. All ideas subject to “SURVIVAL OF THE FITTEST”. Every small change is validated with the UTG (“Let’s UTG it!”) Now I’d like to hand it off to Jelena who will talk more about the importance of usability.
- Hi, I’m Paul Schurr. I’m a developer with Human Resources and Payroll Products. I’m going to talk a little about the experience of being a developer under the USER approach... It’s pretty different from a traditional IT project.
- As developers on a traditional IT project, we would typically receive a detailed set of specifications to code from. On a USER project, on the other hand, we don’t get a spec at all. Instead we participate in a process of designing a product and teasing out the business rules that define it. Our original charter might start out very vague – for example, “produce financial reports” or “make the university’s time and leave collection systems work together”. And the scope may change significantly over the life of the project.
- This can be an inefficient and frustrating way to work. It can be very slow to get started and the work that we do in the early phases often gets discarded as the project requirements change. But it’s also a pretty rewarding way to work. In the end, we build products that people actually want to use. We don’t have to guess about this because we design them along with the people who will use them. It’s fun to be a part of products that people all over campus are using. The User approach gets users thinking like engineers - that is, like problem solvers. I think this has long term benefits for the university as a whole. It also gets engineers thinking like end users – like people who have jobs to do and want tools that make it easier - and who don’t necessarily get excited about the latest, most complicated technology. It’s a real partnership and I think we all benefit from expanding our way of looking at things.
- In a decentralized environment like the University of Washington, it almost goes without saying that the business rules are hard to figure out. Often they don’t exist in any one person’s head and, sometimes, the only way to define them is to get a variety of people together to tease them out over time. This is generally the most complicated part of the products we build. The coding by contrast is almost easy. If we tried to build products like these alone or with a more limited group of people, we would definitely get them out the door faster. But we would probably end up making something that didn’t meet the needs of many end-users and didn’t account for the many exceptions to the rules. And we wouldn’t know that it didn’t work until we launched it and the phone started ringing.
- In the early stages, our main role is to research proposals and to try to help people understand the technical trade-offs as they assemble their wish-list of product features.
- We provide mock-ups to help users visualize the various options. We’ve found that this is crucial because many times the users and engineers don’t picture things the same way. We think we are agreeing when we really aren’t. As the project progresses, we provide increasingly sophisticated and functional prototypes so that users can more fully identify how the product should work. As my colleagues have said, it’s a very iterative process.
- We start thinking about our software architecture early on but we have to recognize that the project requirements are continually refined and that the project will change a lot from beginning to end. So we have to architect with change in mind. This is a lot of work up front but, in the end, it can be an advantage. Given the myriad sources that influence the university’s business rules: federal, state, and local laws; multiple union contracts; various grant requirements; different departmental policies; and so on, it’s important that when we produce administrative software we understand that the rules that drive the application are subject to change. Developing under the user approach drives this idea home from the beginning. Our software needs to be agile; it needs to easily adapt to change. Still, it’s a difficult lesson to learn. It’s one that we’re learning over time and sharing with other developers at the university.
- One of the great advantages of being a developer on a USER project is that we are part of a larger team that can share a lot of the work. Besides helping to design the product… - The product management is handled by the user team leaders. - The team members make a great pool of testers and, when it comes time to recruit larger groups for beta testing, they have the contacts we need. - Team members are also perfect evangelizers of the product because they work with the people who will use it. This really helps us gain campus acceptance for new products. - And finally, having people from customer support and training as part of the team is another huge advantage. Who has a better insight into what confuses end users than the people who provide customer support? We end up with a simpler user interface and a support staff that really understands how the application works and why it was built the way it was. With that, I’d like to turn it over to Erick Winger for a customer support perspective…