[Georgia Tech Stingerette]
Understanding the Problem
Evaluation of the current system
information acquisition process
The Stingerette Escort Service provides call-in, reserved, on and off campus transportation for students, faculty and staff, from 6:00 PM till 2:10 AM. To request a ride, the students call the Parking and Transportation Office and give the dispatcher the number of people that will be riding, the address departing from, and the address the caller wishes to travel to. The dispatcher lets the caller know the location where he/she will be picked up (which usually is very close to the location of the call), and the approximate time (on few occasions) it would take the driver to reach him/her.
Currently the dispatcher uses a
Microsoft Excel spreadsheet, which allows him/her to log calls and enter pick up
information. He/she interacts with the drivers using a walkie-talkie radio. The
drivers depending upon their location decide the routes.
The focus of our project is to
create a better user
interface for the Stingerette dispatcher to quickly and easily assimilate the
data he/she receives and pass on optimal routes to the drivers. We think that
the new system would go a long way in increasing the efficiency of the service
and increase user satisfaction.
The Problem
The Stingerette service is a very safe and convenient mode of transport for students and other users without vehicles. The system however has a few drawbacks, which are outlined here.
The main problem with the Stingerette is that some callers have to wait for extended periods of time before they are picked up. This problem is due to the fact that the Stingerette vehicles do not use optimal routes because the dispatcher does not know the location of the vans. The radio communication is quite unreliable and the drivers and dispatcher have a problem communicating with each other.
The dispatcher as of now is subjected to multitasking due to fact that he/she has to enter a multitude of data, which makes him/her work at a frenetic pace when the number of calls increases.
The Stingerette operation team includes a Supervisor, two dispatchers and 5 drivers. There are essentially two sets of users of the dispatching interface, the dispatcher and the drivers. We reviewed the sets of users, their work environments and their past experiences with a special focus on the dispatcher. The following are the results of our study:-
Dispatcher 1: Female, 39 yrs. Diploma in Management. Has been a supervisor for school buses and has experience with dispatching and transportation services for 15 years. She joined the Stingerette service in May 2002. Her off days are Friday and Saturday.
Dispatcher 2: Male, 48 yrs. College Graduate. He joined the Stingerette service in February 2002. He dispatches on Fridays and Saturdays when dispatcher1 is off, and drives the Stingerette on the other days. Has no previous experience with dispatching but handles it pretty well as of now. Drivers feel he is very clear with his announcements. He is off on Mondays and Tuesdays.
The basic characteristics the system entails the dispatcher to have are listed below.
§ The user has basic computer knowledge, such as working with a keyboard and mouse and entering data into the logging system, which at present is a Microsoft Excel spreadsheet.
§ The user has basic telephone and radio operating skills, which are very necessary for the task he/she performs at present.
§ Since the service deals with routes around and off campus the user has to have a familiarity with the road network.
§ The dispatcher gets a constant inflow of calls and also has to handle the radio at the same time, which can be quite stressful in situations where calls occur very regularly.
§ Callers are from different nationalities and have various different accents. The User has good communication skills to counter this.
§ Since the system entails the User to enter in data for each call, he/she has to have reasonable typing skills to make sure all the data is entered.
§ The dispatchers are trained for a few days before they begin solo operation and thus can easily be taught new procedures.
As discussed earlier we also spent some time with the drivers and noticed and studied their work environments. We took down some information about the drivers.
Driver 1: Male, 55 yrs of age. He is the most experienced Stingerette driver and has been working with Stingerette for 3 years. His duties include training the new Stingerette drivers and he works from Monday to Friday from 1500 hrs to 2330 hrs.
Driver 2: Male, 40 yrs of age, has been working since December 2001 and works from Saturday to Wednesday. He was previously a truck driver.
Driver 3: Male, 45 yrs of age, also has a day job in Parking and Transportation department, in employment at the Stingerette since November and takes Wednesdays and Sundays off.
Driver 4: Male, 20 yrs of age, is a Georgia tech student and works part time at the Stingerette on Mondays Wednesdays and Thursdays from 1800 hrs to 2200 hrs for the past two years.
Driver 5: Is dispatcher 2.
Task Characteristics:
The Stingerette dispatcher has to perform 6 basic tasks
1) Decide Stingerette operation
2) Co-ordinate drivers
3) Receive calls
4) Log call data
5) Inform divers
6) Update data
These tasks are not always performed in sequence and may be interrupted at any time. The major concurrent task is to decide on Stingerette operation where the decision is based on several variables such as number of drivers, number of outstanding calls, time, weather conditions, safety and others. This is a high level task and is always on the dispatcher’s mind. The dispatcher will in some cases consult with drivers before stopping/resuming Stingerette operation and may consider their input while making the decision. The result of the decision has a major bearing on the remaining dispatcher functions as it usually reduces the data entry and updating tasks while giving the dispatcher more time to concentrate on coordinating with the drivers to complete the outstanding calls.
The other major dispatcher task is to co-ordinate between the drivers to make sure that all students are picked up with the least possible delay and are dropped off promptly. This task requires the dispatcher to know and remember in 2D spaces the location of the drivers and the incoming calls so that optimal routes can be plotted. The current system does not allow the dispatcher to visualize the locations and so the drivers collaborate and decide, speaking to each other through the wireless radio, about who would pick up which caller.
The remaining tasks consist of the dispatcher receiving calls, informing the drivers, entering and updating data. These tasks are generally performed in parallel and are not necessarily in a specific order as the dispatcher has complete freedom to do as they please. Since the dispatcher is often interrupted by calls and radio messages he or she must constantly multitask and remember which of the task have already been performed and which ones are yet to be done.
Environment characteristics:
The dispatcher environment is a cubicle in the Parking & Transportation office. The dispatcher sits in front of the computer and has access to a telephone and a radiophone by the side. The cubicle also contains another two computers where the Parking & Transportation night supervisor sits. The dispatcher’s hours are from 6PM to 2:10 AM with a half hour break for dinner.
The office is common to the entire Parking & Transportation department the dispatcher is often disturbed by the Parking enforcement employees on the night shift. The dispatcher also has to answer the phone for the Parking & Transportation department and direct the callers to the appropriate person. The campus police building is also connected to the Parking office and the dispatcher is sometimes visited by Police Officers on their break.
The present form or radio communication between the drivers and the dispatcher is erratic and unreliable and wastes a lot of time as the driver and dispatcher often have to repeat themselves. In certain extreme cases they may even miss calls to each other.
Hierarchical Task Analysis:
0. Perform Stingerette dispatch
1. Receive calls
1.1 Hear telephone ring
1.2 Answer telephone
1.2.1. Pick up receiver
1.2.2. Switch on speakerphone
1.3 If Stingerette is functioning
1.3.1. Find pick-up point
1.3.2. Find drop-off point
1.3.3. Find number of people
1.3.4. Note time of call
1.3.5. Advise on pick-up time
1.4. If Stingerette is not functioning
1.4.1. Say Stingerette service is not functioning
1.4.2 Ask the caller to call at “X” time
1.5. Finish Call
1.5.1. Replace receiver
1.5.2. Switch off speakerphone
2. Log call data
2.1. Enter call time
2.2. Enter pick-up point
2.3. Enter drop-off point
2.4. Enter size of party
3. Inform drivers
3.1. Switch on radio
3.2. Read out new call information (Pick-up, drop-off, party size)
3.3. Note receiving driver
3.3.1. Acknowledge driver
3.3.2. Update data log entry with driver name/number
3.4. Switch off radio
4. Co-ordinate drivers
4.1. Listen to driver requests
4.2. Switch on radio
4.3. Read out outstanding calls
4.4. Note receiving driver
4.4.1. Acknowledge driver
4.4.2. Update data log entry with driver name
4.5. Request drivers to change vehicles
4.6. Pass on road, weather and traffic information
4.7. Inform other drivers of driver/service status
4.8. Switch off radio
5. Update data
5.1. Listen to driver transmission
5.2. Acknowledge transmission
5.3. Update data log
5.3.1. Enter actual pick-up time
5.3.2. Enter driver name/number
5.3.3. Enter no shows
6. Decide Stingerette operation based on number of calls, number of drivers, time, weather conditions, etc…
Plan 0: 1
2
3
do 4 and 5 as required
6 is a continuous process over the entire work day
1 and 2 may be concurrent
Priority: 4, 5, 1, 2, 3 (descending order of priority)
Events with higher priority take precedence over lower priority events and the tasks are then done in that order of precedence.
2 may be interrupted by higher priority tasks
Plan 1: 1.1
1.2(either 1.2.1 or 1.2.2)
If functioning do 1.3 then 1.5
If not functioning 1.4 with 1.4.2 being optional
1.5(either 1.5.1 or 1.5.2)
Plan 2: 2.1
2.2
2.3
2.4
Plan 3: 3.1
3.2
3.3(optional)
3.4
Plan 4: 4.2
4.8
4.1 may initiate 4.2
Perform 4.3, 4.4, 4.5, 4.6, and 4.7 as required between 4.2 and 4.8
Evaluation of the current system [ Attachments at the end of this page ]
The dispatcher works in a cubicle at the Stingerette office and he/she sits in front of the computer and has access to the two telephones by the side. He/she works from 6PM to 2:30 AM.
The equipment used includes
1) A PC with Windows 2000 Professional edition operating system. The application used for data entry is MS Excel 2000 where a template spreadsheet is stored and used every day to enter the records of the calls.
2) A phone to receive incoming calls – has both handset and speaker phone options.
3) A wireless radiophone to interact with the Stingerette drivers- has both handset and speaker phone options.
The Excel sheet used to enter records includes columns for
· Time interval between call received and caller pick up
· Time of call
· Time at which caller was picked up
· Pick up location
· Drop off location
· Driver who will pick up the caller
· Whether call was cancelled
· Whether the caller made a complaint about delay in pick up
· Whether the caller was absent when the vehicle arrived to pick her/him up
The current interface available to the Stingerette dispatcher is rather primitive and basic. The dispatcher has to enter details manually except for the function that calculates the time interval between call received and caller pick up.
The interface demands:
· High typing speed,
· High short term memory
Both of these are stressors for the dispatcher who has to work from 6PM to 2:30 AM fighting fatigue.
Often there is confusion when both the incoming call phone and the wireless from the drivers operate simultaneously; this affects the dispatcher’s auditory perception and patience.
The dialog over the phone is colloquial and often time consuming as the dispatcher takes data from people with different levels of English proficiency. In several cases the caller and the dispatcher do not understand what each other is saying.
The current interface does not allow the dispatcher to know where the drivers are, so usually he/she calls the drivers and leaves the decision about which driver would pick up the caller, to the drivers. This often turns into confusion as the drivers, who also don’t know where the other drivers are, start collaborating with each other and finally end up wasting lot of time and fuel. There are quite a few instances where the drivers make the pick up and then realize the destination of the caller is opposite to the ones sitting in the van. This makes the driver radio the other drivers to find out, which way they are traveling. Once the contact is initiated, the drivers rendezvous at a common spot and transfer the caller from one van into the other. Then the vans take their intended courses and make their drops and pick-ups as scheduled.
The interface does not have short cut techniques in entering data in the log. There is a lot of redundant data entry. And there is no automation for the current time so the dispatcher has to type in the time of call as well. The system also does not automatically provide visibility of system status or feedback to the dispatcher in any way.
The excel sheet has no kind of error correction and or detection built into it. If a user makes an error the help and documentation that is accessible is that of the Excel itself with no help or documentation catering directly to the columns and features of the Stingerette entry template. The PC itself often crashes / hangs during the operation and that requires auto saving the data every few minutes.
The dispatcher needs to have an excellent memory handling the incoming calls information and pick up calls from drivers. Information is basically stored in the dispatcher’s memory before typing into the Excel spreadsheet.
However, the control of the interface and freedom is with the dispatcher because everything is basically manual and there is no intelligent response from the spreadsheet. It is as elementary as using pen and paper and so the dispatcher is quiet flexible in entering the data in the log.
Information Acquisition Process
The process of gathering information about the user and the service involved three sessions with the dispatcher and rides in the Stingerette with different drivers to extract their opinion about the service.
§ Sessions with the Dispatcher: We tried to isolate three different times ranging from when the dispatcher was relatively free to times when he/she would be completely occupied. There are two main dispatchers used by the Parking and Transportation office, whom we shall name as Dispatcher1 and Dispatcher2. The former works from Sundays through Thursdays and handles the bulk of the job. The latter is a Stingerette driver who fills in for dispatcher1 on Fridays and Saturdays. We managed to fit in two sessions with dispatcher 1 and one with dispatcher 2 on taking permission from the parking and transportation office. The two sessions with dispatcher1 were held on Wednesday, 11th of September 2002 from 1800 hrs to 2030 hrs and later that night from 2330 hrs to 0130 hrs. The session with dispatcher2 was held on Friday, September 13th 2002 from 2130 hrs to 2330 hrs. We timed the duration of calls from the users of the service, the time taken for the dispatcher to enter the data into the spreadsheet and the amount of time taken to radio the message to the drivers on duty. We also asked them information about their educational background, the amount of time they have been working with the Parking and Transportation office and their past work experience.
§ Sessions with the Drivers: We spilt ourselves into two groups and went in the Stingerettes and asked the drivers their opinion about the current service operation, their suggestions for improvement. They told us that on all days in spite of 5 drivers recruited by the Stingerette service only 2 or maximum 3 drivers would be present. They added that the service would improve if the dispatcher would know the current location of the drivers at each time. We also took their details about their educational background, work experience.
The user group is small and specific allowing us to tailor our interface to suit the individual requirements of each user.
Both the dispatcher and the drivers have a training period in which they are taught the operation of the system-this will allow us to make ease of learning secondary to the efficiency and ease of use.
Since the user works at the end of the day and handles a lot of tasks with variable motivation levels we infer that flexibility, ease of use and robustness of the interface are very important.
The system must be user pre-emptive, user initiates actions; the interface of the software is more flexible.
Multithreading is important, as the user has to use the interface while handling multiple calls and simultaneously input different data.
The interface must allow substitutivity by allowing short cut menu operations while entering data.
Recoverability is critical, as the dispatcher sometimes has to often change data and any system downtime will badly affect system performance.
The system must also reduce the amount of typing required by the dispatcher by automating some of the logging functions like time entry, address entry, etc…
Provide the dispatcher with information on the locations of the vehicles, vehicle occupancy and boarding and destination locations.
Provide an interface that would allow the dispatcher to communicate with the drivers more efficiently.
Attachments