Tag Archives: business requirements gathering

Analytics professionals need to be communicators

Are we communicators?

Analyics are an extremely hot topic. While there is a lot of talk about it, too many companies are still failing to reap the true benefits from “bread and butter” tools such as dashboards. It’s safe to say that there is a disconnect: lot’s of talk and excitement, yet little true engagement on the business side. What’s causing the problem? It’s tempting to blame the technology.

The Disconnect

Having worked with many organizations over the past decade, I have come to the conclusion that a majority of the problems are caused by needless complexity and by a maddening drive towards technical excellence. Let’s face it – an analytics solution is only as good as the adoption by the user community. Brilliant technology fails when people don’t know what to do with it. How can we fix this? I think we – the analytics professionals – need to look at ourselves and make some changes to the way we work and engage with the business community. It’s easy and comfortable to stay in a comfortable cocoon of technical talk and optimization. Our objective needs to be to step out of that cocoon and start communicating with the business.

The Communicator

Last weekend, I started reading an excellent book by Tim Elmore. The book is about communication. Tim makes the case that our society requires a different communication approach. In the past, we adored the great orators that would read a carefully scripted speech. Today, we relate to people who deliver messages that connect with us. The author drafts up a comparison between the past and today: public speakers (aka technical experts) vs communicators. When I studied this, it struck me: The content applies to our business analytics profession as well. I have taken the liberty to modify it a bit. Take a few minutes to study the table and to reflect how this might apply to your and your team:

Analytics Professional

Are you a technical professional or a communicator?

Need to change

Let me tell you, this comparison really spoke to me. As analytics professionals, we need to make a serious effort to connect with our audience – the business. That requires us to leave the comfortable cocoon of technical talk. Here is an example: the classic requirements gathering. We interview, we document, we ask for sign-offs. The whole process is technical and it usually doesn’t help the business. It’s a process that was designed to help and protect the IT professional. A communicator on the other hand goes further than just creating a thick document. The communicator goes out of his way to really understand the business. That might require a simple prototype. It might require us to take a personal risk and ask more questions.The end result is a better analytics solution.

Here is a suggestion: Print out this table and take a look at it before you head into that next meeting or before you hand over that new dashboard. Think about your team. Are you a an analytics professional or an analytics communicator?

P.S.: I highly recommend reading Tim Elmore’s book. It’s an excellent read. There are  a ton of exercises and self-assessments that help you improve your personal presentation and communication style. I have read many books about presenting and this is belongs in the category of books that can really have an impact.

Related Posts:

Why you should add prototyping to your toolbox

The value of prototyping

Last week, I came across an excellent post by the Truly Deeply blog. It was titled ‘Brands need to Innovate or they will fade‘. The author of the blog argues that brands are under pressure to innovate their products and services. But innovating becomes harder and harder as the “future is less and less an extrapolation of the past“. While this is nothing new and surprising, the post provides an idea of how companies can stay innovative. The writer describes a technique that business analytics professionals need to be familiar with: prototyping.

Prototyping boosts thinking

Dubai Marina

Prototyping helps you explore ideas

The author(s) of the Truly Deeply blog describe how the famous design firm IDEO leverages prototyping to rapidly innovate. Rather than sitting down with a blank sheet of paper and waiting for inspiration, IDEO typically get immersed in a new topic that they are working on. Not only that: they jump right in the water and start prototyping new ideas very early during any given project.

“They refer to it as ‘building to think’ instead of thinking about what to build.”, The Truly Deeply Blog

But why does prototyping work for them? It kick-starts the learning process (see quote above). Prototyping allows them to play with their ideas and to expand their thinking. Let’s keep in mind: theories on a piece of paper rarely inspire. And once you have a prototype, you can start making sound decisions that are based on direct and hard evidence. This in turn can help you with obtaining commitment. This is especially important when people are risk-averse or lack understanding.

“The power of prototyping or pilot testing is you fast track moving to evidence based decision making.”, The Truly Deeply Blog

Prototyping and Business Analytics

I couldn’t agree more with the Truly Deeply blog. Prototyping is an extremely valuable technique. Every business analytics professional should add it to the toolbox. Traditional IT project management taught us that we had to write lengthy requirements and design documents. But the problem with that approach is that business and IT have a very hard time figuring out and agreeing on what is really required. I wrote about those problems a while ago. Prototyping on the other hand allows the analytics professional to rapidly understand the true requirements. At the same time, the business person can quickly identify how the new solution can add value.

Prototyping in Action

Prototyping doesn’t have to be difficult and time-consuming. The new Cognos Insight solution, for example, allows business users to do prototyping by themselves. With Cognos Insight you can not only explore data but also develop small models on the fly. Take a look at the picture below. I started with an empty workspace and developed a prototype for an initiative-based view of my budget. This took a few clicks and some minimal typing. All that in under 2 minutes. And now I can go ahead and play with prototype and test drive it. Contrast that to a dry requirements or design document.

Prototyping with Cognos Insight

Prototyping under 2 minutes

Prototyping creates value

Make sure to add prototyping to your toolbox. It is tremendously helpful and valuable. I argue that proper prototyping significantly increases your success rate. Cognos Insight especially allows you do develop neat prototypes for dashboards, reports, plans, budgets and forecasts. But keep in mind: prototyping should never violate good solid project management processes. You can read more about that in a prior post.

How can you leverage prototyping to advance your thinking or that of your users? What are your experiences with prototyping?

 

Related Posts:

How to create happy business people

“Projects could be so much fun if it wasn’t for the users.” Well, I have often heard this from different project teams. And there is some truth to this: Too many projects fail to ‘wow’ an organization because the business is disappointed about the final results. Based on my personal experience, I believe that the traditional implementation approaches are partially responsible for that.

Continue reading

Related Posts:

Three ideas for better user requirements

Let’s face it. Way too many projects fail. And they often fail because of low user adoption. Users hate the new processes, they dislike the new report style, they are not sure how to best use the new planning software. Project managers claim that the users are not open to change. Sounds familiar? But when we look at it carefully, a lot of the issues boil down to how we gather user requirements.

THE PROBLEM WITH REQUIREMENTS GATHERING

In my very first job, a senior colleague invited me to join a critical requirements gathering session for an SAP implementation. He had prepared an intricate questionnaire (By the way, he called this process a ‘JAD session’ as in Joint Application Development). We met with the users and he rattled off a ton of detailed questions. I was impressed. The users weren’t. They struggled with a lot of the questions and my colleague left frustrated. His message to me was: “Users never know what they want. This is the most frustrating aspect of our business.” To make a long story short, the users ended up not liking what they received. When my team mate pointed at the signed off requirements document an angry user replied: “Sure, I signed off on this document but this is not what I had expected.” This type of situation happens everywhere. But what is causing this problem?

HORROR IN THE KITCHEN

A few years ago, we moved from San Francisco to Europe. We ended up renting a house that did not have a kitchen. No big deal, I thought, and went to the first kitchen store I could find. The friendly sales person started rattling off a ton questions: What type of stove do you want? Have you thought about the size of your fridge? How many liters of storage space do you need? It went on and on. I had no answers for this person. Strange. I love to cook, I spend a lot of time in my kitchen. Yet, I was not able to provide satisfactory answers. And the sales person got frustrated with me. He suggested we take a break and reconvene after I had done some soul-searching. Sounds familiar? Any similarities to the standard requirements gathering process? Well, I aborted the process at that point and found another store that clearly knew how to help me.

A FEW IDEAS

Here are three ideas for making that requirements gathering session easier and to help drive user satisfaction:

  1. Business problems come first: The traditional requirements gathering process focuses on features and functions (which fields do you need in the report, how do you calculate this metric). There is a place for that, but let’s start focusing on what the users are actually trying to accomplish. Ask questions like: “What do you use this report for? What problems are you trying to solve with this? Has this been useful in the past?” We are in the business of solving business problems after all. So let’s focus on that. By asking those type of questions first we are able to make new connections and we are able to guide the discussion proactively. I went to another kitchen store and found a great sales person. He asked me a ton of questions around our family life-style, looked at pictures from the prior kitchen, etc.. He got the big picture. Also, I felt at ease. This person clearly showed an interest in helping me.
  2. Stop asking users for what they want and start showing them how the world could be: We don’t know what we don’t know. It’s that simple. Look at a user who has been using a certain set of paper-based two-dimensional reports: that person would not know how to articulate the requirements for a multi-dimensional online version (What is a dimension?). Instead, build a little prototype and show them how the world could be. Make it easy for people. The person at the new kitchen store did just that. After asking the high-level questions, he used a few models to explain to me what type of decisions I would have to make. He basically educated me. And that did wonders. All the feature and function questions from the other store suddenly made a lot more sense.
  3. Create and share: Don’t just stop there. Take the initial requirements, apply your knowledge and think ahead. Take the input from the general business problem discussion and create a prototype that includes useful things the user might not have articulated. You are the expert and you need to inject your expertise. Apple does that extremely well. Steve Jobs once said: “Let’s go invent tomorrow instead of wondering about what happened yesterday.” And this could be a highly rewarding exercise, because we get to apply our deep knowledge. Also, make sure to show the advanced prototype for early feedback. It is easier to visualize what could be when I actually see it. The guy at the second kitchen store did that. We configured a basic setup and he then applied his deep knowledge to surprise me with a really cool proposal.

THE NEXT PROJECT

Next time you head out to meet with users, try to remember some of these things. It can make a huge difference. I can tell you that my family is pretty happy with our kitchen. The combination of understanding how the world could be coupled with the deep knowledge and creativity from my coach (the sales guy), we ended up with a rather cool setup that continues to delight us. Why shouldn’t we be able to do this in business as well?

“When you fulfill dreams, success is inevitable.”,Carmine Gallo, The Innovation Secrets of Steve Jobs

[twitter-follow screen_name='cpapenfuss']

Related Posts: