#17 - Involve Users in the Development Model of Multinational Corporations - Is it worth it? Experience Report IRCSE '08: IDT Workshop Friday 31 October 2008 Martin Olausson

Page 2 Background Several project results end up in unsatisfied users To be able to deliver a successful software product that suits the users' requirements and expectations You have to fully understand these requirements and expectations To be able to fully understand these requirements and expectations You have to involve the actual users in the development process

Page 3 Background Users are mostly indirectly involved in the software product design through indirect links These links are normally few Studies shows that successful projects consist of several direct links between users and developers To achieve these direct links users need to be directly involved with the software developers

Page 4 Problem Definition Be able to shorten the distance between the users and the R&D organization Project managers usually critic user involvement to be expensive and time consuming If we would be able to prove the incorrectness of these prejudgments we could move the organization towards a more user centric setup Thus a project were assigned where focus was to involve the users in the design process. Targeting configuration of a control system

Page 5 Identify User to Involve in the Project People from product management, line management and R&D upper management with business knowledge to know where they wanted to gain or keep market shares did provide a user profile User profile’s attributes were among others Years of control system experience, age, culture, professional roles, industry and company background Targeting novice user in the age of 40 to 50 years Novice = less than one year control system experience

Page 6 Methods - Interviews Totally 16 open ended questions, each interview 2 hours duration “Please describe what type of continuous maintenance you perform on the distributed control system” Results and lessons learned After 10 interviews the number of unique findings was down to ~4 per interview Ended up to be dialogs, not monologues. Clearly inform the users about our level of knowledge to avoid incorrect expectations Compile information directly afterwards as it often are ambiguous and vague. ~2 hours per interview No culture differences in work flow However the Chinese users did only want to participate in

Page 7 Methods - Workshops Between 2 and 10 users attended Collected information from several users under the same amount of time as one interview Results and lessons learned Only one person, the most experienced, that talked Counted a one interview

Page 8 Methods - User Brainstorming As the users' daily work is focused of using the distributed control system we believed that the users had great ideas of how their problems best could be solved Results and lessons learned The brainstorming session resulted in new requirements instead of what we expected; a pale of solutions ideas

Page 9 Methods - Paper Prototyping Used After the interviews but before starting the actual implementation of the prototype Printed out and showed on face 2 face meetings Time to redesign and test on meetings A fast and effective method for allowing users to gain insight in the proposed design and functionality Results and lessons learned Users' adaptation to this method showed out to be quick As the users saw that their involvement did change the design immediately during the test, they were positive to get involved in further tests

Page 10 Methods - User Tests When paper prototype tests were finished a prototype of the software product were implemented Purpose to test design and functionality and not to be used within the final software product No architecture documents, function descriptions or design document were written Results and lessons learned Conducted 37 user tests (20 for design) The average number of iterations was 2

Page 11 Results To verify results 20 users were identified for a test,10 novice users and 10 advanced users List of 10 tasks to complete without any time limits

Page 12 Results We identified 5 similar projects with the same planned user profile, project schedule and project costs Main reason for the increased costs was that the interpretation of some requirement was changed during the development

Page 13 Summary and Conclusions Establish contacts with users is a time consuming process It is important to start early in the project to identify the user profile and to establish contacts with the users Invaluable input as project gained much credibility towards both steering committee and stake holders The proposed design and functionality were entirely based on and confirmed by the users Great use of detailed log. Statistics were very valuable when defending design and functionality decisions To avoid redesign of the good parts of a products it is important to present users’ positive feedback as well

Page 14 Summary and Conclusions Take care of the users. Too many times the users have invested time in projects by sharing their opinions without getting any further updates of what come out of their contributions Let them know of project outcome Even if your project schedule seems too compressed to involve the users you can still do something Any single interviews, paper prototyping or user tests are so much more than none