The stupid analyst – Nik Gebhard 0

Posted on 3, November 2011

in Category practitioner experience

Here’s the scenario: You walk in starry eyed. A fresh start. A new challenge. An opportunity to learn and share knowledge. The introductions fly past and, if you’re lucky, you remember the name of the meeting’s facilitator. Kerryn. Or was it Karin? Ready – set – go! The conversation kicks off. Most of the stakeholders around the room already know each other. More importantly, they know the business.

No question, no gain

From the onset it’s evident that the project is about replacing the CDS with the QLT. Before long a seemingly uninterested attendee enters the room. It’s Gary from RGM. You remember that RGM is the department that is strongly opposing the project. It’s ok though, because if the system can adapt to the existing LGM and then bypass whatever it is that’s stopping it in GDR, the benefits will greatly outweigh the resistance put up by RGM. Obviously it’s all down to the timing though, because project Wolf is underway and creates a major dependency for this project. The session draws to a close. You look around the room and the stakeholders seem satisfied. It looks like they got exactly what they wanted from the session.

You look down at your notepad and there are a bunch of acronyms, question marks and additional names that were picked up in conversation. Right, it’s up to you. Go forth and do the analysis and deliver something awesome by Friday. Thanks.

This is unfortunately, a position that many analysts find themselves in too often. I know this, because I have had this conversation many times before.

Question all, assume nothing

Let’s replay this scenario. The conversation kicks off and acronym one rears its ugly head. You interrupt the conversation and sheepishly question: “CDS?”  You receive the anticipated ‘idiot’ glare from across the room, followed by: “Yes, Customer Data System. You know, where we keep the customer data stuff…” That’ll teach you to ask stupid questions.

After the fall, you get up, brush yourself off, and brave the next question. “What type of customer data?” “Well, it stores names, addresses, telephone numbers…” There’s a brief hesitation – “And relationship information” shouts a voice from across the room. “Does it?” questions the original attacker. “Of course it does; that’s where we get all the information we provide Marketing.”

Hmm… the attacker needed help this time round. Perhaps they don’t know everything. “What type of relationship information?” you ask. The original attacker cautiously answers, “We store information related to the type of products customers are interested in, so that Marketing can target them specifically.” You quickly fire in the next question, “Is that information collated into specific groups, or is it a free text field?”  There’s a moment of silence. You look around the room in anticipation for an answer. Nothing.

Questions can be more powerful than statements

The question is parked and the conversation swiftly picks up again. Acronym number two comes up and you ascertain that QLT stands for ‘Quick Leasing Tool’. It’s the name of the project after all. The meeting room door opens and a seemingly uninterested attendee sneaks in. There’s a pause and the facilitator points out that this is Gary from RGM. Notice how easily the next acronym snuck in there? You guessed the second one and it’s time to confirm this one. “RGM… Marketing? “Yes, Retail Group Marketing” Gary confirms.

Excellent, we’re making progress. You remember that he’s from the department that is strongly opposing the project. “Can Gary answer the question we parked earlier?” you ask. Gary wraps his mind around the question and immediately expresses his frustration. “It’s a free text field. It’s amazing how many ways there are of writing the same thing!” “How do you target specific customer groups from this information?” you ask. Gary shows more frustration as he passionately explains how a single employee spends their time sifting through the information to identify potential target groups. This is why the communications to customers are always late.

“Why don’t we collate this information into specific groups asks the facilitator?”  Excellent, they’ve asked the question that you couldn’t, because you don’t want to make promises on functionality this early on. Gary explains that this wasn’t thought about when the system was originally designed in 1992. “You mean we can change the way this is captured in the future?” he asks. Gary’s interest in the project has suddenly increased – and so has your value add. “Yes” answers the facilitator. “It’s why we’re implementing this project, to improve the quality of data we get from the system.” Have we just changed Gary’s position from ‘strongly opposed’ to ‘mild interest’?

Stupid questions are only as stupid as the assumptions that support them

So what does this story demonstrate? Part of an analyst’s job is to bring previous project experience and innovative thinking to the table. By asking the ‘stupid’ questions, they break down assumptions and demonstrate to stakeholders why obvious questions aren’t as instinctive as they seem at face value. Stupid questions are only as stupid as the assumptions that support them.

As an analyst you need to challenge what you hear. You need to seek clarity when you’re unsure and most importantly – never assume. Never ever assume. You’d be surprised how often I have asked a question, only to hear someone say, “Thank goodness someone else doesn’t know,” or “I was about to ask the same thing.”  If you don’t know something, it’s quite likely that someone else around the table doesn’t either. And if you are the only one that’s learning from the question, then at the very least you’ll be able to follow the rest of the conversation.

Never be afraid to question, never be afraid to challenge assumptions and never be afraid to analyse. Ultimately, the analyst needs to understand – that’s why they’re there. The only stupid question left to ask is… Why aren’t you doing this already?

What ‘stupid’ questions do you wish you had asked on your last project? Share your experiences below in the comments.

This article originally appeared on Bridging the Gap on 3 November 2011. Click here to view the original article.