Feedback Statistics?

[Guest]

I send out forms to gather feedback on performers/programs that my company
has to entertain patrons.
I gather feedback from both staff and patrons. Staff feedback includes how
well the performer did (were they on time? prepared? etc.) and how well they
were received by the audience (1-5 rating). Patron feedback includes how they
found out about the program, how they'd rate the program and what other types
of programs they would like to see.

I currently keep the statistics in a Microsoft Excel spreadsheet and send
out quarterly reports using the stats.

However, the spreadsheet has so much information, I feel like Excel isn't a
good choice. I have a Staff tab, Patron tab and two other tabs for general
market research. The Staff and Patron ratings though fill up so much of the
spreadsheet it's hard to use it to really gather stats aside from the
complete results (# of patrons surveyed, # of surveys sent, etc.)

Is there a good template or even better program that I can use? I tried
transferring it all to Access, but that seemed just as messy.

Thanks.

 

[Guest]

Rachel,
Part way into reading your request I was going to suggest a relational
database program, such as Access since Excel is seemingly overloading you
with information. Generally I'm thinking it is probably the tool for this
type of situation.

If you were just trying to analyze the results of a single survey, or even
the same survey given at different points in time, Excel would probably
handle it pretty well. But with a mix of several types of surveys (those
tabs) and a variety of each of those (for each performer) taken over a long
period of time, Access or a similar RDBMS would seem to me the way to go.

I suspect that the problem in moving your data from Excel into Access may be
that once you got it all into Excel you may not have examined it to see how
you could optimize it's organization to obtain the information you want
easily. I don't know how familiar you are with Access, but this is a typical
problem with people trying to move from Excel into Access - they still think
'2-dimensionally' rather than '3-dimensionally'; i.e. they leave their data
in the tables created by the data import rather than analyzing it to see how
it can be restructured into multiple, related tables for efficient storage
and data retrieval.

There's a pretty good discussion of the basics of RDBMS published by Oracle
here:
http://searchstorage.techtarget.com/generic/0,295582,sid41_gci1087688,00.html
it gets a bit deep at times (well, those Oracle folks tend to go overboard at
times), but it might be something to read up on. Another good place to look
would be http://office.microsoft.com/en-us/help/HA010563211033.aspx which is
an article Microsoft has put up that uses data in Excel as an example of how
to move it all into Access in a 'better' way. Beth Melton has a good article
on normalization also:
http://pubs.logicalexpressions.com/Pub0009/LPMArticle.asp?ID=88 One more
good read on normalization is at
http://dev.mysql.com/tech-resources/articles/intro-to-normalization.html by
the MySQL folks - an open source RDBMS that is often used to drive dynamic
page providing websites.

While I don't adhere to strict normalization (there are always exceptions to
the rules), until you have a grasp of this basic fundamental of RDBMS
architecture, any attempt to set up a smoothly functioning database is going
to be tough going and you'll probably end up with the attitude of 'there is
so much work to be done to get anything out of it' that so many end up with.
That's mostly because they are trying to make the database look and function
like Excel. Kind of like trying to use the heel of a shoe to hammer a nail:
it can be done, but not nearly as well as with a real hammer.

With the Excel setup you have, I can imagine it's difficult or at least
tedious, to find out what performer was well accepted by both the patrons and
your staff - with Access it would be an easy task. But you have to do some
more learning in the area of creating queries and reports - luckily, Access
has some great wizards to help you do exactly that.

 

[Guest]

Thank you!

I do know a little on Access as I use that for the basis of a Performer's
Database that I also run. I tried to move things around a little, but to me
it was seeming to look exactly as the Excel spreadsheet looks.

The biggest problem with Access is that I have the data available for
librarians to see and most of our Librarians (I work for a Library) do not
know a thing about Access and may not completely understand. I will look
into your suggestions though, thank you very much!

 

[Guest]

Rachel,
I think it would be worth the effort in the long run. You really have to
sit down as a first step and think about the data you have and how it may
need to be reorganized for database use. Sometimes that's difficult for
people to get the hang of.

Look at your data in Excel to see why you may have multiple rows in a sheet
all regarding the results of a single survey. Look for the columns that the
same information repeated many times. Those are columns that could probably
be in a single table as a single entry, with related table(s) set up to hold
the data that has forced the use of multiple rows on the sheets.

I like to use a simple 'rolodex' type scenario as an example. A rolodex or
contacts file usually consists of Names, Addresses, Phone numbers. Where all
of your contacts each only have 1 address per name and 1 or 2 phone numbers
per name, one card (row) per contact works fine. But if a contact has
multiple addresses, and a varying number of phone #s at each address, then
you either start really smudging up your cards trying to cram all the
information into them, or you have many cards all relating to the same person
and have to fumble through them to find the right person's info at whatever
address they may be at today. Think about a situation where you need to
keep up with a person's home and business information, and they may even have
several business addresses (think of a doctor who works at several clinics,
perhaps - as that's a real world scenario I've worked with in helping a
national insurance company put together their physician's directory).

With a RDBMS you'd start off with a top-level table that contained very
unique information about the individual: name, SSAN, birthday,
wife/children's names - things of that nature. Then you have a 'related'
table that contains the address information for the person - one record in
that table for each address associated with them. By the very nature of a
RDBMS, each person can have none, one or many addresses. Then yet a 3rd
table has the phone numbers associated with each address - and again they can
have none, one or many phone numbers of various types (voice, data, cell,
etc) associated with it. You can now rapidly get to Dr. Rachel's 'card' and
immediately scroll through all addresses associated with Dr. Rachel while
seeing all phone numbers associated with each address as you scroll through
the addresses.

If you'd like to continue working toward this end, I'd be willing to assist
you on an "as time permits" basis with it. Perhaps help analyze the data you
have to possibly suggest a table structure for the database to you, and help
from time to time with questions about 'how to' or 'what's the best way' type
questions about it. Although for some things, it could be more advantageous
to ask through the Access support groups. If so, you can reach me through
this email address (remove spaces to come up with the obvious email addy)
Help From @ jlatham site.com