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.
As I mentioned above, it’s imperative that you ask the right questions of your client. To me, identifying the right questions was one of the hardest things to do. So here are the questions I always ask — make sure the client answers these fully, and be sure to include relevant questions tailored to your specific project as well:
Who will generally use the data?
In answering this question, the client might inform you of other people that you may need to discuss the project with. It will also tell you whether the database is to be used in-house or publicly.
How will the data be used?
Is your data simply to be used on the company intranet? Or will the same data need to be available in a different format on the public Website as well? Obviously the options will depend on the job — make sure you ask!
Where is your data now?
Never in my work experience has a client handed me one database or one source that contained all the data. As you seek out data from the client, it will be handed to you in all kinds or formats! Spreadsheets, mainframe data, desktop databases, paper brochures and filling cabinets are just a few.
How much is the data worth?
It’s important that the client knows the value of their data. Just because it’s available doesn’t automatically mean that it should be used. The client should always be informed of the value estimate for all the data available. This means that the client is able to make decisions that may save funds, and make your life easier!
What rules do you want to apply to the data?
Rules can be important for maintaining data integrity. Your client may want contact information in the database to include an email address, a valid street address or the contact’s name, so that the information can be split into separate categories. This is something you must find out in advance, so that you can build the system to your client’s requirements.
Rules. Rules. Rules.
Like just about everything else, most businesses use rules to govern their data. Ever filled in a form that said it needed your email address? Or wanted your phone number broken into three? These are data rules, and they govern how the data should be formatted, what type of data it should be, etc. If the client says they want a first name, middle name and a last name for their contact database, then we consider this a rule. Rules are designed to maintain data integrity, and trust me, if you make them up instead of developing them in lone with the client’s needs, you’re asking for trouble!
Ask your client what rules they have for their data and they generally look at you with a confused expression. It’s never that easy! You’re going to have to search for the rules yourself. Here are a couple of places I’d look:
- Request for Quote or Request for Proposal
- Old Systems
- Reports, Spreadsheets, Forms and Filing Cabinets
These two documents can be a goldmine for data — they’re generally used as a basis for determining the price of the project in, so they’re usually packed with data
Having access to an older database system can be both a blessing and a curse. The information you gather from the old database can give you a good idea about what kind of data you can expect to find. However, unless the job simply involves tweaking this old system, then only use it as a reference point. It’s often easy to think that simply editing the existing database and accommodating new code will finish the job. In a very small number of cases, this may be true, but usually it isn’t.
Just about every company can lay claim to asking customers to fill in forms, having tons of data in spreadsheets, and stacks of information in filing cabinets. It’s guaranteed that the data will be scattered all over the place – but if it’s needed to meet the project’s objectives, then you must find it.
Collecting data so you can develop an accurate schema and, eventually, a successful database that achieves your client’s goals and meets their needs is no mean feat. It’s an intense and often difficult task. But now you know how to interview the client and look for data rules — often the toughest steps in the process. Good luck, and may the schema be with you!
User Interface Design with Sketch 4
Diving into ES2015
Wrapping Your Head Around Python
Designing UX: Forms
Bootstrap: A SitePoint Anthology #1
Jump Start Sketch
Bootstrap: A SitePoint Anthology #1
Jump Start Sketch
- 1 The Freelance Tipping Point: 5 Stories on Leaving the Corporate World
- 2 7 Workflows Entrepreneurs Should Automate with Zapier
- 3 3 Ways to Work More Effectively in a Web Development Team
- 4 Learning to Code after 40: If You Think It's Too Late, Read This
- 5 Oh, the Lengths We'll Go: Extreme Stories on Getting the Job Done