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
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 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?
“Only big dreams have the power to move men’s souls.” Marcus Aurelius
Back in December I was diagnosed with cartilage damage in my knee. This is a nasty injury that often results in people not being able to walk without pain let alone do any kind of weight-bearing sport like skiing or running. As a devoted runner and skier, this was really bad news. But luckily, I found an excellent physio therapist who gave me hope. His advice along with my experience as a project manager has gotten me on a path towards recovery. This journey is reminding me of a few project management principles.
A few weeks ago, I had my road bike serviced by a mechanic who was highly recommended. And so I dropped off my bike. Went through a few basic questions and I asked for an opinion on a number of things. To my disappointment, the guy was pretty quiet and did not provide too much input. One week later I picked up my bike and was presented with the bill. No explanations. Just the bill. So, I payed. I was a bit disappointed. But He definitely did a good job and the price was ok. But something was missing and I promised myself not to go back to the mechanic in the future. So what was wrong? – Pretty much everything except for the results.
SERVICES SHOULD BE EXPERIENCED
My former mechanic in San Francisco was different:
He always took the time to explain things to me.
He involved me in the decision making process (“Which cable do you prefer? I personally recommend this one for this and that reason.”).
He shared cool stuff and news with me (“Hey, check out this really cool new widget!”).
He kept his promises and provided me with clear estimates.
It’s easy to summarize this: The great mechanic involved me in the process and he made me feel good about it. And that’s what it’s all about: good service is an experience. It’s not only about the qualification of the person delivering the service: When I compare the two mechanics, both were highly qualified. The difference was the communication. It didn’t cost the guy a single cent. His total time investment was less than 3 minutes. That’s it. But it made a world of difference to me and he earned my trust.
BUSINESS ANALYTICS PROJECTS
If you are a project manager, solution specialist or a consultant, think about your role for a minute. You are in essence delivering a service to the business. The business is your customer. And just like me and my bike, business people are usually passionate and have a lot to loose and to gain. And they are usually a bit nervous about the implementation. Unfortunately, too many project members and consultants think it’s just about getting the work done and to deliver results. Based on my experience, I would argue that just being smart and that just doing a good job won’t get you anywhere. Instead, we should all try to fully engage with our customers on the business side. We should try to be the good mechanic. Think about your recent projects. Have you done one or more of the following activities:
Keep the business informed about the progress, potential obstacles & opportunities? Do you do this frequently?
Have you taken the time to explain concepts & technology to the business? We should offer this up?
Have you involved the customer in certain decisions? Even small decisions can make the business feel appreciated.
Do you share good news or cool discoveries with the business? Why keep the good stuff for yourself?
When is the last time you tried to surprise the customer? Finish a deliverable a bit earlier, add something extra, do something unexpected. Those little things go a long way
YOUR NEXT PROJECT
Delivering a successful business analytics project requires all of us to deliver great customer service to the business. It’s not only about building a cool solution. The project won’t be a success until the business thinks it’s a success. And by delivering a great service experience during the implementation we can all set the foundation for success. Doing that will help alleviate concerns, increase the excitement and develop ownership. It has worked for me in the past and it is working for the great mechanic in San Francisco. The guy in Munich lost my business. Quality was fine, but I’d rather have fun while spending my hard earned dollars! What type of ‘mechanic’ are you?
“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.
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:
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.
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.
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
Please do not read this post if you are opposed to humor, irony and severe sarcasm.
THE BATTLE CRY
The other day I came across an article in Time magazine about Amy Chua. Even here in Europe we can’t ignore her infamous book “Battle hymn of the tiger mother”. No matter if you agree with her or not, we cannot deny that she has started a pretty heated debate about raising our kids. Just this week I came across various articles about her and had to listen to some radio shows discussing her methods. Even here in Europe. Having heard so much about this topic, Jen and I certainly had a quick discussion about our approach to parenting.
BUSINESS ANALYTICS AND CHANGE MANAGEMENT
Some of you probably attended the Gartner BI Summit in London. As every year, many people discussed the problem of user adoption and change management. Over the years, I have witnessed many different attempts to increase user adoption: town hall meetings, trainings, flyers, videos, candies etc.. Some methods are successful, other methods fail. It always depends on the organization and its culture. During a discussion with different delegates, somebody made the comment that users can sometimes be more difficult than kids. Hmm…that sparked an idea.
ENTER THE TIGER MANAGER
If you follow the discussions in the press, there is heated dispute whether Mrs. Chua’s methods work or not. But since many organizations are struggling with change management, how about trying Mrs. Chua’s methods? How about unleashing the Tiger Manager:
“Nothing is fun unless you are good at it”: Some users resist using business analytics tools. They prefer to stick to spreadsheets. That’s what they know and that’s what they enjoy doing. Could it be that they are not using the new software because they are not good at it? Would it make sense to force users to practice using the new tools? Rather than sending out a friendly invite to attend training, would it make sense to just lock them up? To make this as effective as possible, one should not allow anybody to drink, eat or sleep until the users get better at it. Bathroom breaks should be strictly forbidden during the critical learning stages.
“You are garbage.“: We should all strive for perfection and we all know that poor analysis can lead to poor business decisions. Yet, some users seem to feel that it’s ok to use the new software sporadically. They resort back to spreadsheets and they make mistakes. If we come across somebody like that, we should call that out openly. Instead of offering help, why don’t we openly call those users ‘garbage’. Adjectives like ‘lazy’, ‘stupid’, ‘useless’ or ‘repulsive’ could represent a decent choice as well. The public insult and ridicule will teach these users a critical lesson: ‘You better use the new software and you better get damn good at using it!’. PERIOD
“Sorry. No sleep overs”: Users spend a lot of time on social networks like Facebook and Twitter. They also spend time getting coffee or lunch. All these activities take time away from learning how to use business analytics software. Would it make sense to cut off access to social networks? Also, would it make sense to force the inexperienced users to forgo coffee & cigarettes during the early stages of their learning experience? Also, isolating those users that struggle the most could help? Find them a remote office or conference room? Social interaction is fine. But it should only happen in a highly controlled manner.
“I am going to take all your stuffed animals and burn them.”: Some users are weird. They complain, they refuse, they battle. In other words: they just don’t get it. Soft skills only go so far. For those particular users we should start threatening to take their office decoration away: their favorite coffee mugs, their stuffed animals, their stress balls, etc.. And don’t just stop there. Some users need more drastic measures: smash their coffee mug in front of them, spit on their awards, rip their stuffed animal apart. That will teach them a lesson. And remember: Life is hard after all. Life is a battlefield. This type of experience could help them excel in other areas of their job as well.
What do you think? Seems like a good list of things. Let’s all strive to produce the best end-users a company could ever have! Would love to hear about your experiences with this. Maybe we will be able to read about your experiences in the Wall Street Journal. I could envision something like “Why Tiger Managers are Superior“…….