Gathering Data Made Easy

Gathering data for a new database-driven project, be it a Website or application, is one of the most important tasks you'll possibly ever have to do. Unfortunately, it can also be one of the most stressful, sleep depriving, homicidal phases of completing a project... for me at least.

What's the big deal about data? Well, if you collect the data before you start building the database, you'll be able to compile an adequate analysis for the database design... which we're going to refer to as the <geek term>schema</geek term>. Without a thorough analysis of the data, a situation could easily arise where you find you've formatted required data incorrectly, or left it out altogether. And this is where the sleep deprivation starts, as you realise that the database will need to be edited, or possibly even rebuilt from scratch! Our sanity can be saved with a proper analysis to begin with.

However, it's not only a lack of information that can result in extensive edits, or (cringe) rebuilds of a database. If you try to interpret the information as you collect it, this too can lead to disaster. Thus, at this point, it's important you don't start to think about the actual database schema (let alone beginning any kind of physical structure). Instead, I suggest that you approach the process openly, never straying down a singular path until you've collected all the data, and consulted all parties involved.

Ok. So how would I get the data from the client? I'd interview them.

Interviewing the Client

Why interview the client? Good question. Well, who's the person that's going to build the database, and knows exactly what information is needed in order for you to gather all the necessary data?

You of course!

Sure, in the big, wide (and well-paid) corporate world, there mightn't be much chance of you, the fabled geek in the cupboard, actually meeting the client. But not everyone's in the corporate world, are they? So perhaps your chances of interviewing the client will be higher. Make sure you're prepared for the meeting -- and by that, I mean prepared for the fact that the client won't understand much of what you do.

Unfortunately for us, the majority of clients have a tendency of thinking visually: forms, Web pages and other user interfaces. As a general rule, the client won't really care how the data is structured or how it interacts with their system. Because changing visuals can usually be done easily and quickly, the client may often think this ease applies to every kind of change. So be ready to explain to them the importance of the schema in the overall development process, and the difficulty they'll experience in making changes down the track.

Now, how do I get the right information out of a client? Well, I generally approach interviews with the following points in mind:

Interview Rule Number 1: Be nice to the client and don't make it seem like you're smarter than they are.

The word is "interview", not "interrogate". The client doesn't have your technical expertise, but they have the information you need. It's your job to get to the data. So the best way to approach the interview is tactfully, and to avoid frustrating your client, overwhelming them, or making them feel like an idiot.

Interview Rule Number 2: Enter with an agenda and ask the right questions.

Enter the interview with an agenda, making sure that you're going to cover the important areas, but always retain an open mind. The best opening question might be "What do you want from this project?" Asking this question first will give the client/interviewee the chance to tell you what they want from the project in a way that makes them feel comfortable. It also shows that you're attentive to their needs.

Try to find out their initial ideas about the job, and how they'd like to achieve their goals. This should hopefully give you a clear idea of what they want. Be prepared to listen, and take notes -- lots of them.

Interview Rule Number 3: Talk to everyone who's involved with the project.

Have you ever been in a situation where you're going to the movies with a group of friends, and one person decides what you're going to see? It's annoying, right? Well, this can also happen in the data collection process. If you only use the ideas voiced by the first (or loudest, or boldest) person you talk to, then you may not get the information you need to build a suitable database.

Interview Rule Number 4: Make sure you understand what the client wants.

Making sure you know exactly what the client wants is important. If you don't, you may leave the interview with completely the wrong idea of their expectations. Make sure you thoroughly understand what they tell you. If in doubt, ask for clarification. And reiterate the important points with the client in your own words, to make sure you've grasped what they're talking about.

Interview Rule Number 5: Record what the client is looking for and any important data they provide.

If understanding what the client wants is critical, recording this information is a necessity. Write down all the important points covered by the client. You might even go so far as to record or even video the interview, for a complete and more in-depth set of notes.