1. A Novel Idea in Application Development: Ask the Users What They Want Kimberly Barber Copyright Kim Barber, 2003. 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. What we’re going to cover Basic project methodology Current environment Identifying and selecting users Prototyping Where are we now

3. Basic Methodology Standard project mgmt guidelines Systems theory and ADDIE model Analyze Develop Design Implement Evaluate

4. FSU Student population ~36K and growing Multiple campus locations that use the central scheduling system Main campus, Panama City, FL, Republic of Panama, distance learning, and overseas 15 colleges/schools Engineering: joint college between FSU and FAMU 2 professional colleges

5. Scheduling Analysis Existing Course Schedule Master (CSM) homegrown (evolved from 1970’s Banner system) VSAM with CICS interface ~10K sections in Fall/Spring, ~5-7K in Summer Growth in distance learning since late 1990’s Creative calendaring with multiple start/end dates Fall of 1995: Failed attempt to implement new system Excessive time spent correcting official reports Territorial and laden with turf issues

6. User Envrionment Analysis Nov. 2000 – Jan. 2001 Timing: scheduling takes place 6-10 months prior to classes starting Users are typically tasked with multiple duties in addition to scheduling High turnover rate in users; formal training non- existent Consulted scheduling and registrar staff for list of existing problems

7. User group analysis Direct Users Registrar staff Cashier University Administration for reporting/funding Individual departments responsible for scheduling Enrollment monitoring (Deans) Academic advisors Blackboard, Eval. Services Indirect users Students/Public Maintenance Classroom tech support Dean of Students FSU Police

8. Risk Analysis….. Why do we need that? Preliminary analysis of culture and users? ~1200 individuals with view, ~360 with update High visibility and politically sensitive! Preliminary analysis of systems interfaces Registration, student database, cashiering, official reporting Many legacy systems and batch jobs Created preliminary scope definition and went to AIS; CSM Project is born AKA: CSKim

9. Carefully define user groups you will involve CSM users Administrative areas Advisors Building Services Classroom support Deans Department schedulers Considerations: Don’t mix users groups; shape the message to the group Mix high/low performers, colleges/schools, small/large departments Select leaders in each area; avoid trouble makers or recruit them Early buy-in crucial!

10. With users, timing is everything. Formulated a plan Defined scope and business rules in language they can understand Created scenarios showing how rules would apply Learned about the users How technical are they as a group, as individuals? What are their hot buttons? Who to involve, who not to involve, and who MUST you involve? Don’t involve them until you’ve…..

11. Running focus groups Jan. 2001-Apr. 2001: Prepped them with our expectations Presented scope definition to user focus groups Remember who’s your audience No ER diagrams or schemas; sent materials in advance for review Plan questions before meeting so you ask the same questions of each group Showed very rough screen designs on paper Programmers present for meetings

12. Let them do the talking? Sample questions What’s the thing you hate/like most? What should we keep/get rid of? How do you work? What would an ideal CSM do? Gee, I wish it would….. Is this what you need? What are we missing? Interface: web –vs– CICS Go with the flow Ask follow-up questions Be aware of what they know and don’t know Consider the source Direct the dialog

13. Iterative process:review/revise Apr. – Oct. 2001 Revised scope after each meeting; provided minutes Reviewed expanded scope and rank-ordered 1=need to have 2=nice to have 3=when we can get to it, ignore Scope agreed upon by team

14. To prototype or not to prototype? How complex is the application? Revisit your risk-analysis How many other systems/groups does it touch or serve? Do your users have a clue about what’s coming? How resistant to change is your organization? Kim’s maxim: Its easier to critique than create Pseudo-working prototype created based on final, revised scope

15. Demonstration of Prototype Nov. 2001- Feb. 2002 Scheduled multiple demonstrations; recalled same individuals from focus groups Demonstrated to Enrollment Mgmt and other administrative groups Prototype increased buy-in and comfort levels with change Served as a reality check for work process and business rules

16. Development begins Summer 2002 Core team set up weekly meetings Worked on interface and define business rules Established two web sites Public: client communication to users Private: archive of project artifacts Identified 30 key dept people for continuous input Posted questions on web site/solicited answers by email Set up meetings with external system stakeholders

17. Where are we now? Prepping campus for change Beta testing with pilot testing in July Creating online help and training Analyze Develop Design Implement Evaluate