The annual Information Week 500 Conference just wrapped up in Dana Point, CA, and I had the opportunity to spend time with the CIOs of many of the top IT organizations in the country. Information Week recognizes companies and CIOs for their leadership and innovation, and awards are granted for overall performance and for a number of targeted categories like business analytics, revenue generation, business agility, and customer experience. The overall winner was Paccar, maker of the Peterbilt and Kenworth brands of heavy-duty trucks.
Along with the awards, the conference also featured a number of excellent presentations from industry notables like Rob Carter, CIO of FedEx, Joseph Eng, EVP and CIO of JetBlue Airways, and Bill Schlough, SVP and CIO of the San Francisco Giants (who wore his World Series ring).
My favorite was Paul DePodesta, VP of Player Development and Scouting for the NY Mets. While not much has "developed" with the Mets, Mr. DePodesta was an assistant to Billy Beane at the Oakland A’s and a key architect in developing "Moneyball"; his character is played by Jonah Hill in the upcoming movie. A very quiet and unassuming gentleman, Mr. DePodesta talked about the challenges involved in taking a whole new direction in a business with a long history of doing things in a certain way.
Mobility was one of the key themes throughout, and needless to say, the subject of consumerization came up in a number of sessions. Several CIOs talked about the steps their companies were taking to either "embrace it" or "strangle it", and the strangling option seemed to be getting more than a few nods. I got that impression both from the session and from the side conversations I had with many of the attendees.
There seemed to be a general feeling that if the user was bringing their own device, that should alleviate IT's responsibility to provide support for it. Now I had heard that argument countless times before, and typically responded that regardless of who "owned" a corporate approved mobile device, it was not a good use of the employee’s time to spend hours trying to figure out stuff that a halfway competent IT person could guide them through in a few minutes (or point them to a knowledge base article that would resolve the problem). Given that "cost cutting" was the primary motivation, I had always assumed that such an ill-advised strategy must have come from some "bean counter" with an over-zealous approach to "savings" and a short allocation of common sense. What really blew me away was, this wacky idea was actually coming from the IT guys!
Fortunately I did have the opportunity to address the BYOD option in the overall context of mobility policies in the session I ran on "Mobility: The Next Business Imperative". To put the issue in context, I came up with the following sentence to describe the foolishness behind an IT philosophy of yanking support for user-owned devices:
"Mobility is one of the most important technology initiatives in business today--I don't want any part of it."
When you get right down to it, whether it's IT or networking, we're talking about a "service business". Users are demanding the ability to have a wider selection of mobile devices, and whether these are provided by the company or by the employees themselves (possibly with a stipend to help defray the cost), they are carrying company information and being used for business-related tasks.
People are asking for these tools because they see how effective they are at improving their ability to do their jobs, and anyone working in an IT department should be able to see that as well--hey, we use these things the same way!
Even if it's not a company-owned device, we can't use that as an excuse to slough off our responsibility to support users with something that will benefit both them and the organization--and we shouldn't want to. The typical retort is: "Well then we'll have to figure out how to support 50 different types of phones". The answer to that is "No, you don’t!"
Rather than running to the extremes, the solution to BYOD is to come up with a plan that makes sense to everyone involved, and detail it in a mobile policy that's communicated to all employees. That policy is where you spell out what operating systems and devices you will support, and the nature and limits of that support; typically we don't actually list the device types in the policy, but rather refer to a web page where the list of supported devices is maintained.
Fortunately, there are only three (four if you want to count Phone 7, but even Steve Ballmer admits sales haven’t been what they hoped for) mobile operating systems people will be looking for. The Apple and BlackBerry implementations are pretty standard, though Android's open architecture concept has led to a variety of implementations on different manufacturers and different operator networks. The answer is to figure out which are most popular ones in your environment, and focus on those. With Android, the solution might be to provide one level of support on "corporate endorsed" handset models, and something less for anything else that walks in the door.
Further, "support" doesn't necessarily mean sitting on the phone with a user for four hours helping them to manually enter 300 entries in their address book. Look at how we handle support in other environments. A good deal of the information can be housed in a knowledge base, and for the most common issues we should only have to refer the user to the right support document. A lot of that material is already available on message boards.
IT is not held in high regard in many organizations, and mobility may be the place where we can start turning that around. Make no mistake about it, resources will be required both for evaluating corporate endorsed devices, training for help desk personnel, and building the knowledge base that will be key for getting users to take on more of the grunt work.
