Tag: bi roadmap

Categories
Project Management

What Lego can teach us about implementing Business Analytics

Lego is amazing. Lego is a smart toy. It teaches us and our kids many things. Lego can especially teach us a fundamental insight that is true for many areas of our lives: We love doing those things that we are good at. And this is true for Business Analytics, too.

START SMALL

Success with a small project

Last year my twin boys wanted to build a fairly large space ship. They were really excited but that excitement ended up in a major disappointment: the project was too difficult for them. They lacked some critical skills. They made a bunch of mistakes and they soon lost patience due to a lack of visible progress. My wife and I tried coaching them. But we finally decided to shift their focus on a few smaller projects that they could finish in less than 10-15 minutes. They loved these projects. And they quickly learned new skills and they completed their objects faster and faster. As a result, the complexity of their projects rapidly increased and they got more and more creative. Today, they are able to build fairly large and complex sets and they need very little help from us. Most importantly, they love Legos as it gives them confidence and they are seeing personal success. When they tried conquering complexity too early, they easily got frustrated and Legos ended up not being their favorite toy for a while.

BIG BANG

Over the past few years, you and I have seen many companies fail with their software implementations. There was this infamous word Big Bang and it usually stood for failure. Companies decided to execute long and massive projects. The associated teams ran into plenty of dead-ends, they made mistakes, they had to compromise and they got really frustrated. Consulting cost often exploded. Business users were getting impatient and project teams decided to counter-act that with change management efforts. As a result, many companies literally hate the tools that they spent years implementing. Such a shame.

START SMALL AND GROW BIG

Experience allows us to successfully execute bigger and more complicated projects

When we get started with business analytics we should not attempt to do these large projects. It is just like with Legos: we have to develop new skills and we have to find out what works and what doesn’t. We also have to build the excitement. Small projects allow us to learn and to quickly collect success. The more we learn, the more confident we get. While we might need some consulting help in the beginning we can soon rely on our own skills. That significantly increases the motivation of all stakeholders. You will soon find that people are asking for projects instead of you promoting them. And before you know it you can apply the knowledge and skills to the bigger and more complex projects. And those projects will be successful. Isn’t that a better approach?

My advice to you: Think Lego. Start small and grow big.

 

Categories
Analytics Project Management

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’]