« Immovable Objects | Main | First, Philosophy, then Data Science »

Surviving That First Meeting

In a recent on-line forum, someone asked for guidance on the "basic questions" a Data Modeler should ask of their business customers in the initial meetings. It's a good question to ask, and it's encouraging that this person should think about getting this right.

Rather than provide a list of questions -- which, I think, depend very much on the circumstances of the project, the organization, the meeting invitees and your own standing in the group -- I thought it better to offer some advice about preparation.

Few things are relegated to the dustbin of wasted time than a meeting with an unprepared analyst -- especially the "outside consultant" who arrives expecting to be given a history of your business. When you arrive at that meeting, the chances are that there will be 4-5 people who have been with the company for years and been with each other for years, and 1 or 2 outsiders who just got off the boat. If the meeting dissolves into a history of the business, 3 people will be interested and 3-4 will be bored. That's a waste of time.

So -- advice to the consultant:

It's important to come to that first meeting prepared. You should do research in advance of the meeting, particularly with respect to organizational goals and history, and with respect to business jargon -- words, acronyms and names that are commonly used by the business people.

For goals and history, obtain that from the head of the organization, or as high up as you can get (the decision maker). Find out what that person perceives to be the problem to be solved or the solution to be brought. You might get that from other statements the decision maker or the company has made elsewhere, or (if you're lucky) you can get a 15-minute meeting with the decision maker personally. Use that insight to know what to highlight in your meetings. Occasionally, ask if the business people are in line with the same goals and concerns, and make note of where they diverge.

For jargon -- save everyone's time by knowing in advance what those acronyms reference. You can get confirmation in the meeting, but don't dwell on the subtleties and nuances of the terms. This is especially true if you are an outsider -- a consultant or contractor brought in to a client's area. If you encounter a new term, you'll need to make a judgement about it -- if you let people talk long enough, you may be able to figure out (guess) what it means, and avoid breaking the flow of the discussion. If it is critical to understanding the conversation, ask what it refers to but don't let that term become a diversion. "What does 'ATF' stand for?" is a better question at that point than "What does 'ATF' mean?". In later meetings, you can dive into the meaning, history, usage and significance of the term.

While you need to learn about the business process, remember that your focus (as a Data Modeler) is on the data and on the data's lifecycle. What are the things that they need to have or know at the *end* of the process? Where does that knowledge come from? How does that knowledge get to its end state, and how does it change along the way? Is this something they already know in their organization, or is it new data that is being imported or invented?

By doing your research in advance, you'll be equipped to do both analysis (understanding what is being said) and synthesis (putting what is said into a proper context) during these early meetings. You'll also be equipped to keep the meeting on point and in focus, and to know when the discussion is going off track.


TrackBack URL for this entry:

Hosted by Yahoo! Web Hosting
[ Yahoo! ] options

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)