Project plan and Project focus

Here we present our project plan and project focus:

Project Plan

1. Client information

ISLO is an Eastern Finland Sports Institute based in Joensuu. The institute promotes participation in sporting and fitness activities for all ages in the region of eastern Finland. It offers educational programs and services in a variety of sports and fitness areas as well as training courses in fitness. ISLO is part of the Finnish sports and fitness networks. It is one of three regional sports institutes in Finland and it is maintained by the Eastern Finland Sports Institute Incorporated, which belongs to City of Joensuu.

Apart from sport and fitness trainings ISLO offers additional services such as: aerobic, accommodation, dining and solarium. Aerobic is offered every day in the late afternoons and evenings. Anyone can participate in the classes. There are 16 different classes to choose from. A customer can buy a single entry ticket, monthly ticket or season ticket. Three classes Body Pump (Pumppi), Step Pump (Pumppi Step) and GymCircut (Kuntosalicircuit) require pre registration due to limited amount of equipment (free weights-plates, barbells and an aerobic steps). The booking can be done one week before the class by phone or by visiting ISLO office. The list of registered participants is kept on paper in a file. We will investigate the possibility of designing an electronic system for booking the aerobic class at ISLO.

In this document "user" refers to ISLO and more particularly the term "users" refers to the people working in the club.The term "customer" describes a person willing to participate in a aerobic session at the club.

2. Purpose of the observation

The purpose of the observation is to conduct contextual inquiry. By observing and interviewing the users we will collect the data that will help us to understand the current paper based system and design equally good or better electronic system. We hope to gain an understanding of how the users solve problems encountered while using the current system and what needs they have.

3. Workforce and tasks

Moderator: Monika Zych-Laine
Interviewer: Monika Machunik
Observer/recorder: Paweł Niechoda

The Contextual inquiry script

The first step is the conventional interview. We introduce ourselves and explain in detail the purpose of our inquiry. We promise confidentiality and start to record. We explain to the user that her work is the priority and we want her to guide/teach us through her work and correct our mistakes. Then the interviewer begins with a couple of general questions about the user's work. The interviewer also asks about the opinions on the tools that the user uses. We will try to create a partnership relationship between us and the user. This phase should last for not more than 10-15 minutes.

The second part is explaining to the user the main principles of the contextual interview we want to conduct. We ask the user to do her job as usual, and describe what she is doing. We notify the user we want to ask questions during her job and we point out that she should tell us if the moment is not good for explanation and make us wait. This part should take only about 30 seconds.

After this is the main part of the inquiry - the user does her job and we observe it and try to interpret it. In case of any doubts we ask in order to clarify the problem. If there is not enough customers willing to book an aerobic session, we ask the user to make some fictional booking (or change/remove a booking). The length of this phase depends on our needs, but it should not exceed 30-35 minutes.

The last part is the interpretation of our observations. We describe to the user how we understood her work, and user gives feedback. If there are any misunderstandings, user should explain and clarify them. This phase should last up to 15 minutes.

4. Times and dates

The observation will take place on Thursday, February 5th 2009 at 10 am.

5. Tools needed

Notepad, pen, digital camera, voice recorder

6. Focus questions

The questions will focus on the users' activities connected with bookings and managing the bookings of aerobic classes. We will also try to discover the strengths and weaknesses of the existing system. The planned set of questions we intend to ask is as follow (in no particular order):

• How often do you use computer? Are you familiar with web browsing, using email box, word processor?
• How many bookings (changes/removal) do you do approximately per day/week? How long does it take you to deal with one customer?
  
• What do you find the most annoying while making new (removing/changing) bookings?
• Do you keep the old data? What are the reasons for doing so?
• What do you like about the current system?
  
• What kind of data concerning the client do you need while making (changing/removing) a booking?
• Who is allowed to make/change the booking?
  
• How many people usually do the bookings at the same time? Do you have any other departments where it is possible to book the classes?
  
• During what hours it is possible to book/change/cancel bookings?
  
• What kind of needs do you have for the new system?
• Describe what have you been doing today since you entered the work

In addition to contextual inquiry methods we may consider using other methods that will help us to find the real roots of actions. For example, PD methods, the why-why-why method.

7. Areas and tasks to observe

We will focus on the current system, users, their current environment as well as their attitudes towards computerized systems.We will focus on the ways the work is currently being done:

• Booking
  
• Changing of bookings
  
• Removing of bookings
• Communication between customers and interested parties (e.g. aerobic instructors, aerobic participants, etc.)
  
• Customer information
• Maintaing and managing the current data
  
• Weaknesses and strengths of the current tools
  
• Visual appeal of the current system
  
• The layout of existing paper schedule
• The type of customers' data stored in the file (e.g. names, telephone numbers, if this is the first visit, etc.)
• The order of filling in columns, as well as possible dependencies between the data in columns
• Possible exceptions in handling particular customers
• The environment in which the users' work is being done (the amount of noise, if the users work in a rush, etc.)
• The way of communication between the user and the client (e.g. if the customers come to the club in person too book a visit or maybe they phone or write an email)
• The level of computer skills of the users
• Possible restrictions resulting from possible disabilities of the users (e.g. color-blindness, poor eyesight, ...)
• Possible need for concurrent access to the data
  
• Any other issues regarding the existing system introduced by the users during the interview

Project Focus

1. Current System

Currently ISLO is using paper based system for booking aerobic classes. There are three classes that require booking: BodyPump (Pumppi in Finnish), StepPump (StepPumppi in Finnish) and GymCircuit (Kuntosalicircuit in Finnish). BodyPump takes place on Wednesdays 7-8pm and Saturdays 4-5pm, StepPump takes place on Mondays 7-8pm and GymCircuit takes place on Tuesdays 5:30-6:45pm. Each class on each day has a separate registration form. A registration form is an A4 paper sheet with information about classes (name, day, time) and two tables. The first table is meant for the bookings and consists of 45 cells (as there are 45 places) where customer information (first and last name) is stored. In case the first table is full and there are still more customers willing to participate in the classes they can put their name and phone number to the second table which is meant as a 'waiting list'. All the registration forms are kept in one folder. The forms in the folder are separated with interleaves. When a person willing to make a booking, opens the folder, he/she is required to choose an interleaf that corresponds to the class that he/she wants to make the booking for. The bookings can be made by a person working in an ISLO office or by a customer visiting the office. The customer can ask for the registration folder and put by herself her name on the list. If the customer is not able to visit ISLO office, she can call and make the reservation by phone. In the same matter changes and cancellations are being done. If the list is full (i.e. all the places are booked) a customer can put their name on the waiting list. In such case, if there is a cancellation from the original list, one of the users will call to the person on the waiting list and inform that there is place available. If the person is still willing to take part in the class, her name is moved to main list and erased from the waiting list. The cancellations can be done the latest three hours before the class starts. Before the class, a registered customer has to come to the office and obtain a pass for the class. The pass for the class is given by the user who also marks on the list (by using colorful highlighter) that the person has picked up the pass on the list. The passes are then collected at the beginning of the class by the aerobic instructor.

2. Presumed Solution

Our goal is to design an electronic system that would replace the existing, paper based one. The solution introduced to the users should be equally good or better than the existing one. By equally good we mean that it should not be more time consuming that the current. In addition, it should be at least as easy to use as the current one. Currently, both the user and customer can make the booking so the new system should also take this into consideration.
The main functionality of the system will be: booking the class, removing the bookings, and changing current bookings. If needed, we will extend the functionality, by adding features supporting users' work. We will also explore new needs for any additional functions that might be needed.

3. Supported Tasks

The new electronic based system should have the same main features that the paper based systems. Users should be allowed to do the same tasks as in the paper based system. The features can be categorized as:

• The main features:
• managing bookings for aerobic classes
  
• The necessary features:
• booking time for aerobic classes
  
• editing existing entries:
• changing the time
• changing the place
• canceling the classes
• browsing existing entries
• removing the entries
• searching/filtering the entries by
• class
• date
  
• customer data
• The desirable features:
• editing existing entries:
• changing the aerobic instructor
• changing the client data
  
• searching/filtering the entries by
• place
  
• viewing the entries by day/week/month
• support for concurrent access to the data
  
• automatic notification for the clients (e.g. by email) in case of cancellation or changes of the classes

4. Opportunities and risks

The electronic system can provide a quicker and more convenient way of managing the booking. Furthermore, the storing and archiving the data will be more comfortable and secure. We hope to design the system that will allow concurrent access to the registration.The system may also decrese the amount of work required in managing the bookings. Moreover, if the system will be online, it would allow the users the remote managing of the bookings.

The main risks of the new system is that it will be too difficult to use and the user will not be willing to learn the system. What's more, the user may be too used to the old system and even though the new system will be easier and more efficient to use, he/she will not want to switch. Another risk lays in the fact that due to too many available functions, the GUI might become too complicated and not intuitive. The users may also fear the data breach and loss in the new system. In addition, the new system may be too expensive for the users.

As for the risks of the project there is a great danger of falling into fixed way of thinking about the design of an electronic schedule, as there is a lot of existing solutions for similar purposes (e.g. google calendar). Additionally, we may overlook important aspects of the users' work by regarding it as being predictable. An example of another risk is that the user will not be willing to cooperate as we won't implement the solution and they may not be interested in the results. Furthermore, there might be not enough communication between the client and the interviewer or we may run out of time.