#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 theusers 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 email

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