IOM 533 Systems Analysis and Design

Jay Miller System Design Project Final Report

Prepared for: Prepared by:
Professor Ann Majchzrak Hong Fang
December 14, 1998 Susan Kerpan
Robert King
Neil Lennertz
Project Name: Jay Miller
Client Address: 1138 South Glenville Drive
Suite #2
Los Angeles, California 90035
(310) 550-6349 (phone)
(310) 859-8146 (facsimile)
Client Contact:
Since our first meeting at Junior's Restaurant, which was an interview type meeting, we have had 6 subsequent
meetings with Jay at his business location. The first of these meetings was observational; the second and
fourth meetings were participative design; the third and fifth were prototyping meetings; and the sixth meeting
was purely training. Additionally, in the fourth meeting, we worked with Jay to set-up a computerized calendar in
Outlook for each bank client.
Our first memo suggested that an observation of Jay's operations was required. Team members met with Jay in
order to observe both the workflow and Jay's personal work habits. We were able to extract valuable insight into
Jay's needs assessments, both stated and unstated. This has made the team aware of the needs which the
proposed IT system must fulfill.
The participative design format of the second and fourth meetings provided two benefits: First, we were able to
clarify with Jay his needs, potential users and report types required for his business. Secondly, we provided Jay
with a "mock-up" interface utilizing MS PowerPoint. These demonstrations allowed Jay to visualize what we had
conceptualized, and provided Jay an opportunity to make inquiries about our processes and thoughts.
The team's third and fifth prototyping sessions provided Jay with his first glimpse of his business process
visualized in ARIS and a quick run-through in Access of the new database. We were able to walk Jay through
the flow to further ensure alignment between the "as-is" business model created in ARIS and the actual tacit
business process.
During the sixth meeting, one team member met with Jay for about 1/2 an hour to again work in Outlook.
Throughout the entire project, we have had interspersed meetings with Jay to show him how to better utilize
Word, Outlook and Access.
Initial Project Specifications:
A. Project Scope and Business Case
In conjunction with Jay Miller, we have defined the project scope as generating new business. We view the
process of generating new business as having two major sub-processes: 1) obtaining the bank as a client
and, 2) obtaining clients for the bank he represents. For purposes of this database project, we are
concentrating on "obtaining clients for the bank Jay represents." Again we anticipate the system would be
more of an operational Information System to work in tandem with Jay, instead of an "Expert System" that
would help drive the business process.

As demonstrated in our attached ARIS "as-is" process, areas exist within Jay's business process where
data are not currently collected. This presents "areas for improvement" in the "to-be" process. As an
example, the tracking of disqualified clients is one such area. This allows the collection of data that can be
used to help define contact lists for existing clients and matching potential contacts through cross-selling
opportunities with other banking institutions he represents.

We have identified the benefit to Jay as increased efficiency and ability to schedule more clients in a shorter
amount of time. The benefit to the bank is a faster return on their investment (Jay works more efficiently
and provides them with greater output).

Metrics for Jay's business can be defined in the increased productivity the "to-be" process should provide.
Specifically, this would include the increased number of client calls in a given period, an increase number of
scheduled appointments, the ability to cross-sell contacts to other client banks, and the ability to provide
statistical reports to client banks to help enhance his business base.

Jay would be the sole user. The motivation to use such a system would have to come from Jay himself.
The thought of increasing his efficiency and productivity was very appealing to the client. Jay Miller has
thoughts of increasing his business base within the next five years. In order to accomplish this, a more
efficient system would need to be implemented.

B. Functional Specifications
The need for human interaction is significant; he will still need to contact the client and make the very-
human determination of whether or not a client is sufficiently worthy of an interview with the client bank. The
Information System will allow Jay to input information and capture information that would have otherwise
been lost regarding a client. More importantly, such a system would allow Jay to track possible trends in the
business markets.

Dealing with bank information: The "Generate Business" process does not obtain contact information
through a link with the bank's data system. Instead, an electronic version of this customer information is
provided by the bank or ABI in comma delimited format. The IS will accept the comma delimited format file
and import the data directly into the client database table.

User's decision on customer selection: The user can select a particular group of customers based on zip
code, credit letter, his previous experiences, or some other criteria to establish a searching hierarchy. This
process is a decision procedure managed by humans and augmented by the sorting ability of the Access
system. The IS will allow the user to select a search criteria upon which to sort the contact data.

Identifying potential customer interest: This is a combination of performance by the IS system and humans.
The user needs to call targeted customers one by one to identify their interest in the bank service. If
customers need services, then the user will go further to ask some questions related to the customer's
credibility, making a decision whether to make an appointment or not. If customers do not need bank
service, then the user can use the IS system to record the customer's information. The IS will also allow the
user to input information regarding reasons for eliminating, deferring, disqualifying or accepting the contact
as a potential customer for the client banks. Additionally, by using Outlook, the user will be able to schedule
"call-backs."

Availability to make an appointment: The user needs to judge whether he should go any further to set up
appointment for the customer. He can use certain criteria to make judgement, such criteria as loan amount
and company's operating performance, as well as some financial ratios. If customer's credibility is OK, the
user will set up an appointment between the customer and bank's sales and record the appointment in the
IS system.

Screening and rescheduling the customer's selection via IS system: The IS system will help the user to
reschedule and repeat the selection procedures, picking the particular customer group, which have never
been selected or have been needed reconsideration, based on the criteria mentioned in # 2. The IS system
can pop out and screen the customers by the orders given by the user at a certain time period.

Issuing daily report and weekly billing invoice: For each call, the user needs to track the time consumed for
the customer. At the end of the day, the IS system will receive an order from the user for terminating the
whole day task. The IS system then automatically summarize the records and prints out a detail report with
all the appointments during that day, which the user sends to the bank via fax, informing the bank to prepare
meetings with the customers. At the end of the week, the IS system prints out bill invoices for the services
which are executed during the current month.

The system would be based upon the Microsoft Office suite and will be self-contained. It does not need to
directly interface with other systems, though electronic download from ABI or other information providers
would facilitate the process and decrease Jay's response time.

The usability of the system would be high. It would require little effort to understand the system and learn to
operate it. It should be written to almost "mimic" Jay's style since his is the sole operator of this proposed
system. Also, the system should be relatively maintenance-free. Jay himself would then test the system.
The stability of the system is reliant upon the Microsoft Office platform. As such, we anticipate the system to
be very stable.

Business rules for Jay Miller are relatively straight forward: 1) There cannot be two meetings scheduled for
the same bank officer at the same time, 2) Clients must claim to be qualified and must be willing to talk to a
loan specialist for a business loan or line-of-credit.

C. Hardware/Software
Jay Miller's personal computer is relatively new and as such, it already contains Microsoft's Windows 95
operating system and Office 97 suite of products. The hardware platform should be more than adequate to
handle Jay Miller's needs.

D. Implementation
Implementation should be relatively easy. Jay will be involved in testing and reviewing the design
specifications. Once coded, Jay will be utilized as the "tester" in the evaluation of the system. Any design
flaws or feature enhancements can be made at the test phase. Training will occur concurrently since Jay is
(as stated before) our tester as well. Rollout will begin once the tests have shown a complete and desired
system. We do not see any significant restrictions in the installation time or skills required. Implementation
of an Access database will occur on or before December 7, 1998. As the final project is due on December
14
th
, this will allow us to iron-out an "bugs" or difficulties in the system.
Possible Risk Factors
We believe that risks can come in the form of lost data. We would, then, encourage back-ups of the databases
to insure against data corruption of file deletion. Depending upon the amount of data to be warehoused,
physical size (space) may become a limiting factor as well. A final risk factor is Jay's current comfort level with
PC-based applications. We anticipate overcoming this potential risk factor by one-on-one training and by
providing a user manual.
Additional risks come into play with the vast number of records the Access database will handle. One potential
hurdle is whether or not to append subsequent bank clients (roughly 10,000 records per bank) to the existing
client contact table or whether to subdivide the table in some manner. This will affect how queries are designed.
Additionally, if we do subdivide the table and create dummy tables for future bank clients, this is an additional
activity Jay will be required to learn. Not subdividing the records would likely result in a client contact table that
exceeds 100,000 records and we fear this will slow down response time.
Methodology for Data Collection
Again, we collected data on the "as-is" process first by asking Jay to explain the process to us (interview style).
Secondly, two members of the project team observed Jay in his work environment for a one-hour period, taking
notes against the process, as we had understood it so far. In our third meeting, we presented Jay with our initial
interpretation of the process in Power Point. This lead to more of a participatory design model since our
interpretation was very broad and general. Jay helped us to fine-tune it more. In our last meeting, we had
incorporated Jay's earlier comments and created the "as-is" prototype in ARIS. Again, a few changes were
made and a discussion of the "to-be" process was initiated.
Changes to To-Be Process for As-Is Process
1. Contact list sorting
2. Tracking of eliminated, disqualified, or not-interested contacts
3. Incorporating use of Outlook for scheduling appointments
Our first change occurs in the initial sorting of the contact list. The disk, which Jay receives from ABI, has
numerous fields and we believe that sorting on some of these fields may lead to a better hit-miss ratio. For
instance, the ABI files include a field called credit letter which grades the banks clients on an A, B or C letter
grade. We believe that Jay can increase his hit-miss ratio by calling the A customers first. This helps to
ensure that the bank clients called will be credit worthy and gives Jay the opportunity to focus on the most
qualified candidates first and least qualified candidates last.
Additional sorting options can include whether the business is owned by a male or female or by city. This gives
Jay the option to offer specific services to the bank such as increasing the number of loans to female owned
business or target a specific city in which the bank has a particular interest in gaining clients.
As Jay calls the contacts, he will also be inquiring about their current gross annual income. He may choose to
re-sort on this information later.
Our second change in the to-be process model is the tracking of disqualified, eliminated or not-interested
clients. In each of these steps, we will include a note section that allows Jay to put a specific message if
needed. Value-added information may be used as either a cross-sell opportunity or as recommendations to the
specific banks. This can broaden the type of service and information Jay can offer to his clients. Certainly, we
anticipate identification of trends with the not-interested clients and this knowledge may lead to new sorting
criteria in the future.
Our third change is the incorporation of Outlook in Jays process. He currently uses a different paper calendar
for each bank that he represents. By setting up a calendar for each bank in Outlook, he will be able to provide a
weekly schedule of established appointments for the BDOs. Also, he will now have the ability to search for
appointments and will have an archived system.
Each change should provide Jay better tracking information which will ultimately lead to better sort criteria and
the ability to optimize the number of hits for a given contract. The concept is that as patterns emerge, Jay will
be able to anticipate which businesses to call and which to avoid. This will increase his available time, which
can then be focused on obtaining new clients. The feasibility assessment for each change is high. Indeed, we
have helped Jay to create bank specific calendars in Outlook and is currently setting appointments in both the
computerized calendar and in the paper calendars until he feels comfortable for a complete transition.
Job design changes include prioritization of the calling procedure, which will increase available time for
obtaining new bank clients. Storing results over time will allow for cross-marketing in the future. The process
design changes include the three improvements we have outline above. In conclusion, the IS changes include
incorporation of a database into his current environment and the use of Outlook for calendaring appointments.
II. Acceptance Testing (Neil)
Acceptance testing will be conducted in two phases, alpha and beta. These test phases will cover the functional
components of the new system.
A) Alpha Test Plan
A1) Test Objectives
The objective of the alpha test phase is to verify the stand-alone and integrated functionality of the systems
functions:
switchboard operation
data import
time logging
information entering
contact sorting
report format
invoice generation.



A2) Test Scenario
The test scenario will consist of real data obtained from current client banks used in a simulated and controlled
environment. Alpha testing is intended to test the functionality of the system with the intended user. Therefore,
Jay will be asked to perform the following function with direction from the development team:
switchboard operation
data import from comma-delimited text files using import specs
into new table
into existing table
template duplication
logging into the system
specifying client to which effort is directed
specifying starting time
entering client, BDO and contact information
noting appointments made for each contact
sorting of contacts based on criterion selected by the user from a predefined list, e.g.,
ZIP code
Gender of owner
Annual revenue
Appointments made
SIC code
report format selected from predefined list of generation formats, e.g.,
Hit-miss ratio
Appointments made by selection criterion
logging out of system, i.e., specifying ending time
Invoice generation.
A3) Data Collection
Data will be collected through the following methods:
direct observation of Jays actions and responses to the system
observation of the systems response to Jays actions, i.e., action completed or warning generated
recording the ability of the system to perform the required functions
getting feedback from Jay on the system operations and performance
reviewing system outputs, e.g., performance report
A4) Expected Results
Each individual function should be able to operate independently as well as in conjunction with the other
functions. The alpha test will be considered complete upon the successful operation of the aforementioned
functions.
B) Beta Testing
B1) Test Objectives
The objective of beta testing is to verify the continued proper functioning of the systems as well as the ability of
the user, Jay Miller, to operate the system successfully
B2) Test Scenario
Since the beta test uses real data in a real environment, the test scenario will consist of an actual situation in
which Jay conducts normal business operations, using the To-Be process, without intervention from the system
developers. The acceptance test will consist of a complete iteration of the business process consisting of the
following steps:
starting the system
using the switchboard to select the login/logout function
logging into the system for a specific bank client
importing data from the client bank
sorting contacts based on user-selected criteria, i.e., ZIP code
calling a contact and entering appropriate information, i.e., business qualifications
generating reports on pre-defined call performance ratios, i.e., hit-miss ratio
printing the report for analysis
logging out of system for the client bank
generating an invoice for a client bank.
B3) Data Collection
Data will be collected through the following methods:
direct observation of Jays actions and responses to the system
observation of the systems response to Jays actions, i.e., action completed or warning generated
recording the ability of the system to perform the required functions
getting feedback from Jay on the system operations and performance
reviewing system outputs, e.g., performance report
B4) Expected Results
Without developer intervention, it is expected that Jay will be able to successfully operate the system and his
speed will increase over time as his familiarity with Access develops. The system should be able to complete a
complete pass through of the data entry and calling process from entering the initial data into the system and
logging in to logging out and generating an invoice. The IS will be considered accepted upon the successful
completion of these tests. In the event of a failure, the system will be fixed and any system function affected by
the failure will be retested.
III. Training (Susan)
As stated above, training began at the inception of this project. We have worked with Jay to better understand
some functionality within Word and we have taught him to use Outlook, which alleviates the paper calendars
and provides archiving of information.
For the database portion of his business, training accessories will include:
On-site training with the sole user, Jay Miller
Access training to be conducted between the alpha and beta testing
Further training on Outlook is necessary. As this is out of scope for this assignment, we will
work with Jay after the class ends.
A user-manual
An approximately 3 page user guide which will outline how to log onto the system, how to import
information from the bank, how to run reports
Difficulties encountered by Jay in the beta testing that the developers observe will also be
addressed in the user guide for future reference
The training schedule includes:
Logging into the system/switchboard operation
Importing information to Access. This is a crucial step for Jay since he will be required to do this for
all new bank clients
Accessing client information in Access
Logging time spent on each client
Sorting client lists by
Gender
Zip code
Annual revenue
SIC codes
Appointments made
Inputting information into Access
Running reports
Creating invoices
All training will be conducted in face-to-face sessions with Jay. Some familiarity of the system will be obtained
in the alpha test, to be conducted on December 3, 1998. Our first training session will occur on December 10,
1998 and the beta test will occur on December 13, 1998. Difficulties with the system identified in the beta
testing will be modified on December 14
th
.
Final installation of the Access Database occurred on Sunday, December 13
th
after the Beta Test. The
database was fully populated at this time. During population and training, we observed some unforseen issues
in the business contact report which will require additional work. This work will be completed and installed as a
running change at a later date.
IV. Job and Organization Changes (Hong)
After the implementation of the IS system, the job would be changed significantly.
Who
The sole user is Jay Miller.
Job Content Change
By the means of IS system, the job content will be changed dramatically. While most jobs are done by IS
system, the user can spend more time on expending new business, contacting more banks and making more
telephone calls. Most importantly, the user can spend more time on designing new development methods,
improving the working efficiency and effectiveness. The IS system will really liberate the user from more manual
practice and time consuming work. The following aspects are the major changes of content.
Importing information to Access data base: This is a new job content, and the user will use software to
transit the customer information provided by the banks to the formatted data table in Access
Screening customer: The IS system will screen the customers according to the criteria the user inputs
into the computer, such as zip code and credit grade
Taking note: Instead of taking notes about the contacts manually, the user will use the IS system to
record the contact results
Tracking customer: The IS system will track follow-up contacts and retry contacts. Also, the IS system
will track eliminated, disqualified, or not-interested contacts
Summarizing: The IS system will provide a summary of appointment record at the end of day. It will be
sent to the bank via fax by the user
Issuing daily report and monthly bill: The IS system will provide a daily summary report including the
contact results and appointment made during the day, which was previously done by manual practice.
The IS system also will provide monthly bill for the service rendered by summarizing the total monthly
appointment records
Decision marking: The user can spend more time on decision marking issue, such as selecting screen
criteria, contacting more banks and customers, and marking development strategy. By the means of the
IS system, the user can change his working method and behavior, using more effective way to improve
efficiency and to generate more business
Job Schedule Change
The working schedule for an entire day will keep the same as that before the implementation of the IS
system
The process schedule for a call will keep the same as that before the implementation of the IS system
Organization Change
Present: The organization of the firm will keep the same
Future: With the efficiency and quality performance of the IS system, Jay Miller will generate more
business. It is obvious to see that there will be an increase in serviced bank numbers, customer lists, and
daily phone calls. Jay will take organization change into consideration
V. Installation/Implementation/Cutover (Bob)
Installation
The installation of Jay Millers database project will not require significant effort. Jay does not employ a
database driven system of any sort. Consequently, few installation concerns will need to be addressed. Jay's
implementation strategy will come in the form of the "Big Bang" concept. An empty database will be delivered to
Jay Miller and later populated with live client data at his place of business. Jay already possesses Microsofts
Office Suite (inclusive of Microsofts Access) and will not require any additional software to operate this
database. The empty database can be delivered on diskette or e-mail to Jay Miller. Once delivered, the
utilization of the database simply requires the copying of the database (.MDB file) to Jay Millers Access
database directory.
Implementation
Selecting the appropriate implementation strategy requires a review of Jay Miller's operation. Jay's business
must continue to operate during the transition period. The desired outcome from an installation option is to
minimize the impact of the installation (disruption) to Jay's business activities. Additionally, the system must
continue to operate as Jay learns to navigate through the different forms, switchboard and report options. This
system will represent a fairly drastic change to Jay's current methods and will require a deliberate effort by Jay
Miller and the Project Team to ensure a smooth transition.
We have selected the "Big Bang" method of implementation for Jay Miller. Jay currently does not have a
"legacy system" to be phased from. This method of implementation will provide Jay with a fully populated
database which he can begin work on immediately. This will reduce Jay's downtime and enhance his ability to
learn the new system while continuing to contact potential clients.
Implementation will require the efforts of the Jay Miller team. Implementation will involve the population of the
database, the evaluation of data integrity, test-run of the switchboard, forms and reports and final approval by
Jay Miller. We anticipate that any further functional changes to the database, user interfaces or reports will be
noted at this time for future enhancement. The database structure has been set at this time and will not be
altered barring any major issues in the database design that causes data or functionality issues.
Cutover
Jay Millers database project is intended to assist Jay in his business process and eliminate redundant
paperwork. Because Jay did not employ a database prior to this initiative, no legacy system needs to be
integrated or terminated.
Cutover from Jays manual process to the newly generated automated process will require a phased installation
and gradual implementation. This will enhance Jay's knowledge of the database's functionality. Jay will
continue to operate his manual process for the majority of his accounts and utilize the new system for a single
account during this transitional period.
Once the transition period has concluded, Jay will have the ability to import his bank clients and contact
information into the new system. This will eliminate Jay's manual process and system cutover of Jay's new
database management system will be complete.
Time Spent With the Client
In the planning phase of the database, time was spent with Jay in the 6 meetings described above. Each lasted
approximately 1 hours, for a total of 9 hours. Additionally, phone calls with Jay accounted for another 2 hours
worth of interaction.
As we began the implementation and installation, more time was spent with Jay. Part of this time was spent in
training, but the majority of the time was spent in tailoring the reports and functionality of the database itself to
his needs. At this point, we have spent approximately 14 hours in the implementation/installation and training
phases.
Due to new problems that have been identified in the last 48 hours, we estimate that another 8 hours will be
needed to be spent with Jay in training him on the import process of the system and in the report generation
phase.
Total time spent with client is (will be): 33 hours.
In addition to the time spent with the client, approximately 100 additional hours were spent in developing the
process models, prototyping the database, modifying the processes, and creating the final database program.
Process Diagrams and Charts
As-Is Process
Bank Client Needed
Contact Bank BDO
BDO Contacted
Offer Services
Services Rejected Services Accepted
XOR operator
Request List
List Rcvd From Bank List Rcvd From ABI
XOR operator
XOR operator
Initial Contact Screening
Initial Contact Screening
Contact Eliminated Contact Kept
XOR operator
Call Business
Business Contacted Contact Deferred Contact Eliminated
XOR operator
Asks for Decision Maker
Decision Maker Available
Decision Maker Not Available
XOR operator
Defer Contact
Determine Interest
Contact Deferred
XOR operator
Business Interested Business Not Interested
Discard Contact
Contact Discarded
Prequalify Business
Bus. Qualifies
Business Disqualifies
XOR operator
Schedule Appointment
Appointment Scheduled
Document Activity
Appointment entered in Log
Appointment entered in Log
Determine if End of Day
End of Day Reached
XOR operator
Day Not Over Return To Initial Screening
Log Work Hours
AND operator
Fax Appointment List To Bank
Day's Activities Completed
AND operator
Determine if End of Month
XOR operator
XOR operator
End of Month
Not End of Month
Generate Invoice
Invoice Generated
Send Invoice
Invoice Sent
Close operations for day
Business closed for day
To-Be Process
Initial Contact Screening
Call Business
Business Contacted
Contact Deferred
XOR operator
Asks for Decision Maker
Decision Maker Available
Decision Maker Not Available
XOR operator
Get Bank
Clients
Contact List
Processing
Login
Processing
Login Completed
Sorted List
Note Reason
for Elimination
Note Reason
for Deferment
Contact Record
Contact Record
Determined to
Pursue
XOR operator
Determined Not
to Pursue
Business Not
Reached
Decide to
Pursue Contact
XOR operator
Pursue Contact
Don't Pursue
Contact
Defer Contact
Deferment
Documented
Reason
Documented
Contact Record
Select
Sorted List
XOR operator
Zip Sort
Selected
SIC Sort
Selected
Non-Sorted
List Selected
Credit Sort
Selected
XOR operator
Unsorted List
Decision Maker Available
Determine Interest
XOR operator
Business Interested
Business Not Interested
Prequalify Business
Bus. Qualifies
Business Disqualifies
XOR operator
Schedule Appointment
Appointment Scheduled
Client
Appointment Calendar
(Outlook)
Post Call
Processing
Document
Non-Interest
Document
Disqualification
Disqualification
Documented
Non-Interest
Documented
Documented
XOR operator
Contact Record
Contact Record
Bank Criteria
Business Contact
Business Contact
Business Contact
Bank
Invoicing
Report
Generation
OR operator
Function Diagram
Asks for Decision Maker
Bank
Invoicing
Call Business
Contact List
Processing
Contact Sorting
Decide to
Pursue Contact
Defer Contact
Determine Interest
Document
Disqualification
Document
Non-Interest
Get Bank
Clients
Initial Contact Screening
Login
Processing
Note Reason
for Deferment
Note Reason
for Elimination
Post Call
Processing
Prequalify Business
Schedule Appointment
Jay Miller
Pre-Call
Processing
Post-Call
Processing
In-Call Functions
Report
Generation
Organization Chart
Jay Miller
Jay Miller
Testing Plan and Results of Testing
Our testing plan involved an "in-house" test to ensure that all forms, switchboards, queries and reports worked
as intended. To facilitate this test, we intended to use actual client data to ensure a smooth implementation.
After the in-house test, we planned for the Alpha and Beta test program. Specifically, we wanted to observe Jay
utilizing the database and capture and thoughts or comments he had while working in the new environment.
Furthermore, we wanted to fully populate the database during and after the Beta test to ensure that no
functional problems would occur in the database.
The testing phase began with a "run-through" by the Jay Miller team. Using a small sampling of client data that
was provided to Jay by ABI, we were able to create an import specification and successfully import the data.
Once done, we were able to run through reports and forms to ensure that the data was being displayed in the
fashion we had envisioned.
The testing plan then moved forward to an Alpha test. This Alpha test had Jay utilize the system while we noted
any problems to be corrected during the Beta test phase. Overall Jay seemed pleased with the system and its
functionality. We were able to further enhancements to the reports to suit Jay's needs. Neil noticed the need for
a "help screen" and one was implemented for the Beta test phase.
During the Beta test phase, we were able to watch Jay and instruct him on the functionality of the system.
Although the system is menu driven, we were required to provide some training on the user interface. During
the Beta test phase, we were able to import a complete data set from Citizen's Business Bank. During the Beta
test phase and the subsequent training phase, we noticed an error in the business client entry form and plan to
correct this error at a future date.
Users Manual
We have created a user's manual in Microsoft's PowerPoint. PowerPoint was used so we could capture screen
shots and provide Jay with a presentation of his User's Manual. Due to the complexity and size of this file, we
have attached the User's Manual as an addendum in MS PowerPoint.
Results of Training
Areas of difficulty were identified in the training process, which have necessitated the need for further refinement
of the database. For instance, though a help screen was added to the database that fully outlines all of the
steps needed to import files into the Access database, the client has called twice to express his unhappiness
with the difficulty of this step. The simple reality is, however, that we cannot modify the way Access imports
information - that is a job for Microsoft. We must, therefore, spend more time with Jay on this aspect of the
process to increase his comfort level. Also, we will reinforce that he should utilize the help screen as a means
of learning to solve his own problems.
In our first training session, the intention was to allow Jay to sit at the computer and for him to follow our
instructions in going to the different areas. The reality is that we did more of a floor show of the program and
did not give him enough time on the system. Again, we are spending more time with Jay to allow him to search
through the system for things he is trying to do and for us to sit by as last ditch resources of information.
In our second training session, Jay was walked through each step of the process and was shown how to access
all of the reports he needs. Today, however, he has called telling us he needs to be able to print out information
for his employees. When asked if he had tried to use the Reports Generation option, he said no. This
indicates that the most recent training session was not completely successful since he was shown how to do
this. It also indicates a need for the user to explore the system on his own a bit, so that he becomes more
comfortable in navigating through things.
Finally, at this stage, the user is not completely comfortable with using the database. Additional time is being
spent with him this week to fully resolve any further issues.
Need to document the User's testimonials and get final client signoff
Lessons Learned
Managing the clients expectations is important for final satisfaction. Further difficulty in this area
comes when the designers do not know the functionality and capabilities of the program. It is easy
to say sure, we should be able to do that, but if you dont know the program, you could be opening
a can of worms.
If the client is not very familiar with computers, throwing a database at him is both a scary and
difficult thing for him to master. Suddenly, he is expected to not only learn how to use the reports
and search functions of the database, but must also learn how to import information. The initial
learning curve is very steep in this case. The User needs to be told that there are things he will
need to learn.
A database is not the solution to a process - rather, it mimics the process and enhances the
information gathering techniques during that process.