Pragmatic BYOD - 6 Considerations to Enable Employee-Owned Devices

This blog is about, if nothing else, pragmatism. How do we take the conventional wisdom and best practices of the world outside my company, and make them useful in the real world of supporting real end users. With that in mind, I was annoyed to come across an article on CFO.com (CFO, Don't Buy That Phone!) which presents the benefits of BYOD, or "Bring Your Own Device", with the rosiest of rose-colored glasses. A particular paragraph got my attention.

Jim Buckley, CFO of mobile-device management firm MobileIron, points out other savings: “In a BYOD program, end users take more responsibility for their devices, taking the initiative to fix them themselves rather than involving support, and, because it’s their personal device, they take better care of them.” Another cost benefit Buckley identifies is that “companies no longer have to deal with the device life cycle. Smart phones and tablets generally change every 18 months. That’s a lot of new technology the enterprise no longer has to keep up with.”

This is consistent with the conventional wisdom around BYOD right now: That BYOD inherently reduces the cost of IT support because users will be more prone to take care of themselves. I ran that by one of our service desk reps, and he just started laughing. Uncontrollably.

For BYOD to have any chance of driving real business value, several other things must also be done.

1. You must invest in a robust mobile device management (MDM) system, that allows you to keep corporate data and apps secure, regardless of the device being used. Good MDM tools do exist, but they take money to buy and people to maintain the system and support the end users.
2. You must invest, possibly significantly, in the technology infrastructure to make the data and apps available to a broad, diverse set of devices, with users needing to access the systems from anywhere. Cloud will help with that, and will help a lot. How many companies can make their legacy systems available in the cloud quickly and securely? We're moving it that direction, but it will take time, money, and people to get there.
3. Unless all your legacy systems and data already exist in a cloud-accessible app, you must invest heavily in virtualization technologies. You are probably providing some virtual services already, but just wait. The investment is about to get huge.
4. Who owns the device? The "YO" in BYOD stands for Your Own, meaning that we are frequently talking about a device owned by the employee themselves. This isn't a shared assumption in many cases, however, so policies must clearly identify ownership. At the very least, identify the differences in expectations and support between employee-owned and business-owned devices.
5. Expect investment in support services to increase in the near term. This is not like letting a corporate VIP use their MacBook instead of your standard HP laptop. You've probably invested in a highly standardized environment, which allowed you to minimize the FTE needed to support desktops and laptops. Now you have hundreds of different devices that employees may use, and they will expect you to know how to assist them with each and every one.
6. Keep expectation-setting positive. The last message you want to send your business partners is that IT needs to limit their (presumed) productivity. Start talking about what can be done. For example, you could create an internal blog of the adventures of a user's BYOD journey.

Don't get me wrong. BYOD is a necessary evolution of knowledge work. It is not a fad, and it is not going away. What does concern me is the sense that CFOs can just start allowing users to bring their own devices, and we can instantly reduce a few IT support headcount, or reallocate them to growth-enablement roles. Hey, these devices support themselves! When they need help, the users can just go to the service provider or manufacturer, right?
BYOD, cloud, mobile, consumerization ... whatever you want to call this wave ... it will soon become mainstream, standard operating procedure. This is a very good thing, which will provide significant value to most organizations. It opens up knowledge workers to more individual control, and more creativity, leading to better ways to achieve results. Don't be afraid.

Social Media in the Enterprise? That'll Never Happen!

I just had an interesting exchange during an identity management planning discussion. We were reviewing fields included in a new HR system for possible mapping into the ID management system, and saw that fields to capture Facebook and Twitter IDs were included. Most folks in the room started laughing. I mentioned that social media handles or IDs will be included in internal employee directories sooner rather than later.  The reactions ranged from scoffing to comments like "scary."

Whether Twitter or Facebook accounts specifically will transition to the corporate staff directory remains to be seen.

Do you doubt that some method for sharing social media accounts across the mainstream enterprise will happen soon?

I'm sure some forward thinking organizations already do this, since it's made it to at least one HR system's default fields list.

Sidebar: I know there are social media management tools that allow companies to create internal social networks. Often it's an add-on to a suite of tools for monitoring and managing your company's social presence. That's an interesting start, but what individual wants to actively participate in a closed social network with yet another social account or persona? There are only so many people out there who participate in more than one social network/tool, especially when that network doesn't allow you to auto-link with Facebook. I have active Facebook, Twitter, Google+, and LinkedIn accounts. I'm not normal (insert you're joke silently here). Enterprise social management tool vendors should design their tools so that internal staff can easily choose what content to include or not include from their existing social network of choice.

Back on topic, what do you think? Will (or should) companies look to integrate links to employee social media profiles? Obviously it would need to be voluntary, but the upcoming dominance of digital natives will take care of that. What are the benefits? The drawbacks?

Rethinking the Role of Incidents in Service Management

I once had my accounts at a bank where customer service was very good at resolving errors in my account. However, I ended up needing to call them almost every single month to get an error resolved. I don't bank there anymore. Imagine this bank using the slogan, "We fix account errors faster than you may expect!" Do you want to invest in that bank? Then why does ITSM's primary message often sound similar?

• We outperform Incident SLAs 90% of the time
• We've reduced the negative impact of changes by 60%

Do you realize that what we're saying in business terms is, essentially, "We fail less frequently"? Is that the message you want to send?

I'm not saying these measures are bad, or that we shouldn't tell our business partners about them. It's just that focusing our metrics around these types of measures implies that the reason we get a paycheck is that we can fix the problems created by the very systems we deployed. In other words: we're good at fixing our failures. I know the reality is more complicated than that, but is your business partner wrong to arrive at that conclusion?

Service value is based on business value. Period. Business value means increasing revenue, decreasing costs, increasing goodwill, or improving outcomes around a corporate strategic plan. Even at the non-profit where I work, value is based on one or more of these four factors. You might replace "goodwill" with "mission impact", but it is effectively the same thing.

Why then do we put so much emphasis on self-reported issues as a proxy for value? Self-reported issues were the easiest way to collect data regarding the value our services. It doesn't make it a better way, or even a good way; just an easy way. Let me ask it another way: are self-reported incidents a good way to measure effectiveness of service management? Of course not, and for three very good reasons:

1. Self-reported incidents only tell us about things that hurt service consumers to the point that they have no choice but to contact us. Most people don't care enough to reach out, until the pain is so great that it cannot be carried any longer. What about all the non-reported defects?
2. Service management is about ensuring the service consumer is getting what they need from the service. Incidents only tell us about broken stuff, which barely scratches the surface of ensuring the service consumer is getting what they need.
3. Self-reported incidents tell us almost nothing about service value. How do they tell us about increased revenue, decreased costs, or increased goodwill? They might tell us a little bit about increasing or decreasing costs, but even that is a stretch. Even if tracking self reported defects could tell us something useful about cost control, it's still effectively telling the business IT is getting better at fixing our own failures. Again not a bad thing, AND nothing to crow about, either.

I propose that incidents should not be limited to service interruptions; and even if they are, they should cover ALL service interruptions, not just the self-reported ones. I want to take it further, however. Service Management needs to be more closely tied to Customer Experience Management. The book "Outside In: The Power of Putting Customers at the Center of Your Business", written by analysts from Forrester, provides an excellent overview and model for implementing customer experience management. Forrester provides a mini overview on their blog. One characteristic is mapping the intended customer experience for your product or service.

My idea is to take the intended experience for a service, and compare that to the actual customer/user service experience. An "incident" then becomes ANY variance between the expected and actual experience. They could be good or bad things. I want to know about errors, of course. I also want to know about the ways the users of my service do things differently, and possibly better than, the way we expected it to be used. I'll know a lot more about the value of the service this way.

This requires a bit of imagining the future, but it can be a near-term future. Developers can focus efforts on gathering and reporting customer experience with their apps. Would there be a market for applications that could allow configuration of customer experience standards? I know I would be interested in purchasing an app that, in addition to it's user functionality, included this sort of capability.

In the mean time, we can use many of the tools we already use for measuring customer experience. First, however, we need to document what we expect that experience to be and what it should provide.