Planning for Bring Your Own Device (BYOD) (Part 3)

If you would like to be notified when Brien Posey releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.

If you would like to read the other parts in this article series please go to:

Introduction

Throughout this article series, I have approached the subject of Bring Your Own Device from a security standpoint. Although security is arguably the most important aspect of a Bring You work Own Device implementation, it is far from being the only thing that must be considered. Some of the other important considerations that must be addressed are supportability and cost. I will discuss both of these aspects in this article.

Supportability

During the early part of my IT career, I spent several years working the helpdesk at a large insurance company. Because I was young and just starting out, I wanted to make sure that I learned everything about IT that I possibly could. I spent countless hours (even away from work) reading everything that I could get my hands on that was related to IT. I took great pride in having a very diverse set of expertise. In spite of all of my hard work however, I quickly learned two important things.

First, I realized that it is impossible for any one person to know everything that there is to know about IT. Believe me, I tried to learn it all, but doing so is impossible. There is simply too much material to learn.

The second thing that I learned was that even when you think you are on top of your game, end users can throw you a total curveball by asking some of the most bizarre questions imaginable. I never cease to be amazed by some of the strange and unexpected service requests that I received.

So what does all of this have to do with Bring Your Own Device? Well, think about the way that IT worked in the days before Bring Your Own Device. If a user had a problem with a computer, printer, smart phone, or any other piece of equipment that was issued to them by the IT department, then they would expect the helpdesk to be able to fix the problem.

This wasn’t necessarily an unreasonable expectation. After all, the IT department issued the hardware to the user. This means that the IT department had presumably tested the device to make sure that it functioned properly and that it fit the end-user’s requirements.

Now let’s fast-forward to today. For decades end users have been conditioned to call the helpdesk any time that they have a problem with a computing device. This mentality does not go away just because you allow end-users to work from their own personal devices. If an end user has a problem accessing a particular network resource from their own personal tablet device, they are probably going to contact the helpdesk. This is where the trouble can start.

The first issue that can sometimes occur is that the helpdesk staff might not be totally familiar with the device that the end-user is trying to use. This can lead to their inability to solve the problem, or it can mean that it will take longer to correct the problem than it ordinarily would have if the user had been using a device that was more familiar to the helpdesk staff.

To give you a more concrete example of what I mean, consider this. For the last 20+ years I have made a career out of working with all things Microsoft. If my Microsoft Surface tablet suddenly began having trouble connecting to my wireless network, I would probably be able to fix the problem relatively quickly because I spend so much time working with Microsoft hardware and software. However, not everyone in my house uses Microsoft products exclusively. My wife owns an iPad. If she suddenly started having problems connecting her iPad to the wireless network, I would probably be able to resolve the problem eventually, but it might take me a while simply because I am only somewhat familiar with the iOS operating system.

In a household environment the extra time consumed by the repair would not normally be a big deal. In a corporate environment however, the extra time that it takes to correct the issue can be very problematic.

There are very real costs (tangible and intangible) associated with helpdesk calls. The longer it takes to resolve a helpdesk call, the higher the cost of that call. Furthermore, if a helpdesk technician spends an excessive amount of time trying to resolve someone’s issue then there are likely to be other people who must wait to be helped until that issue has been resolved. This contributes directly to lost productivity on the part of the end-user who was having the problem and for all of the other users who are having to wait for help while the first user’s problem is being handled.

Of course all of this assumes that the end-user who is experiencing the problem only has a minor configuration issue that can be eventually resolved. It is also important to stop and think about what will happen the first time an end-user experiences a hardware failure on a personal device.

Because the organization did not purchase and does not own the end-user’s device they are presumably not under any obligation to pay for a hardware repair or a replacement device. The helpdesk staff will essentially have to tell the user that there is nothing that they can do. Some users will accept the diagnosis and move on. However, I have also seen users throw an absolute fit and demand replacement hardware. When the helpdesk refuses, these irate users have been known to go to upper management and try to have the decision overturned.

Even though this type of situation might seem a little bit far-fetched, I have seen it play out in the real world more times than I really care to think about. That being the case, my advice is to come up with an end-user device supportability policy before you ever allow end-users to begin participating in any sort of Bring Your Own Device program. Having a policy in place that the users are required to sign off on can save the helpdesk staff from having to entertain ridiculous support requests.

So what should a supportability policy include? For starters, I recommend that the policy include a provision stating that the helpdesk is not required to support any device that is not owned by the company. That isn’t to say that the helpdesk won’t support end-user devices, but rather it gives the helpdesk the right of refusal in the event that a user has an unfamiliar device, a severely outdated device, or is being rude or abusive to the helpdesk staff.

It is also a good idea to make a statement within the policy that the helpdesk will not spend more than a certain amount of time diagnosing problems on personal devices. That way, if the helpdesk cannot fix a problem in a reasonable amount of time then the policy allows the helpdesk to give up on the problem, and move onto something else.

Finally, it is critically important for the support policy to state that the helpdesk will not be responsible for performing hardware repairs or for replacing damaged, lost, or stolen devices.

Conclusion

As you can see, a Bring Your Own Device program can place a significant burden on an organization’s helpdesk. As such, it is necessary to have a support policy in place before users are allowed to work from their personal devices. In the next article in this series, I will discuss some of the commonly overlooked cost considerations for Bring Your Own Device programs.

If you would like to be notified when Brien Posey releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top