Know the Why

by Brian Katz on May 9, 2012 · 4 comments

Let’s start this post off with the conclusion first. You need to know the why before you can spend any time focusing on the how. Too many people focus on the how to do something and never spend enough time focusing on the Why. The irony is, they ended up wondering why things didn’t work out the way they planned.

If you look at this in practical terms, before you decide to go mobile you need to know why you want to go mobile. What are the business objectives for the initiative in the first place? When your company decides it wants to jump on the bandwagon of BYOD, why are they doing it? If the objective of the BYOD initiative is to save money, does giving a stipend for voice and data use makes sense? If the objective is to let users be more productive and be able to do work from anywhere, have you already decided that it’s okay to expose your data to devices that aren’t physically attached to your network. These are just some of the sample questions you can ask yourself but you have to determine the business objective behind what you’re doing before you do it.

The next step is to figure out your use cases. Lets be clear that use cases are very different from requirements. A requirement may be that you want to share documents as well as edit them. The use case talks about why you are doing this. The use case might be that you are sending out daily notes that need to get input from people wherever they are and don’t require the ability to track changes or manipulate photos. It’s an easy one to meet the requirement. On the other hand, the use case might be that you have excel spreadsheets that contain pivot tables that you want to manipulate and edit. This is much more difficult as there isn’t a good spreadsheet editor/viewer that can handle pivot tables on most mobile devices. In this case, meeting the requirement may be very difficult and require some different options that haven’t been thought of.

I attended a vendor briefing recently where they discussed how they built one of their apps. They took a desktop program that they had and created the UI in storyboards. They then prettied it up and made the UX workable. The last step was to complete the actual programming. At no point did they ask the users how they would use this tablet app, they just made an assumption and created a how. They really didn’t have a use case or problem they were trying to solve and ended up with an App that wasn’t well received.

In another case, my team met with a vendor that had a fantastic product. They were just coming out of stealth and they had plenty of users. The first thing they did was demonstrate the product. They then described why the product was so terrific. They mentioned the problem they were trying to solve and how this product was the best thing since slice bread to solve it. Let’s be clear, the entire room loved the product, including me. Of course, they had a problem, in all the wonderful hyperbole around their product; they had assumed what their why was. When I asked how it helped achieve the business objective we were looking for, it took a minute for the CTO of this company to recover and answer the question. I then asked them if we could take pieces of their product and use it to solve different business objectives that we had. In all, I came up with at least 7 different use cases for their product while they were only selling one. As useful as this one use case was, it really wasn’t the problem that we were trying to solve. The meeting ended well and we will keep talking, as their are plenty of ways we might be successful incorporating this vendor, but not until we can match up our whys with their solution.

This is a problem that many companies face, whether they are looking to roll out BYOD or corporate owned mobile devices, they have to understand what the business problem it is that these devices solve, not as one person from another enterprise mentioned to me recently, “Oh, we’re rolling out tablets because the CIO thinks they’re cool tools and we will become more efficient with them.” This is a rollout that is destined for at least short-term failure because the use cases and business objectives were never discussed.

I recently talked about the need to have an Acceptable Use Policy (AUP) and how this is quite necessary, whether for a BYOD program or a corporate owned mobile program. The AUP isn’t just a document that says what not to do, but also lets you know what you should do. It clarifies the business objectives of the program and usually some use cases so people understand how to use their device.

Remember, when you have a hammer, everything looks like a nail. The problem is the use case required a pipe wrench.

{ 1 comment… read it below or add one }

Martijn Linssen May 15, 2012 at 5:33 pm

Splendid Brian, and very nice examples too.

Ever since the divorce between Business and IT, this issue has worsened. Although admittedly IT has becoming increasingly complex, it also has become an business line of its own and driven by technology rather than business

In my LOB, Integration, the approach is simple: take the Business requirements, put them next to IT (Information Systems) limitations, fill the Gap, and off you go into a few possible directions, each with its own short-, mid- or longterm pricetag

That’s not how we humans operate though. We usually want a bigger car because that damned neighbour (now what does he do for a living?!) got one, and more plastic enhancements for the wife or better yet, a complete new one, while carefully caressing our own one-pack

In our rush to compete, and our initial drive (how does he do that and get away with it?!), we quickly pass the point of no return and become absorbed by incidents and issues that prevent us from reaching our perceived goal – indeed exactly because we did no have a clear Why and roadmap from the start

By the way, I have used a chissel many times to fasten a screw when it was only one screw a day and I had the chissel right next to me. There should be a law against people carrying hammers


Leave a Comment

{ 3 trackbacks }

Previous post:

Next post: