The Problem With Social Collaboration On IT Projects

I was just putting the finishing touches on our company's bring- your-own-device policy when Sam, our CEO, dropped by for a chat. I eventually got around to the BYOD strategy, mentioning the planned move from company-issued BlackBerrys to employee-paid, personally owned devices of choice. "This is going to be a big change for some of our staff," he said. "You better socialize this."

"Socialize" is one of the über-buzzwords of the day. To socialize an intention is different from communicating, explaining, or discussing it. It requires taking communications to a new level of importance and intimacy with the organization. In fact, to socialize an intention means it's further from implementation than you might expect.

Socializing generally involves communicating from one to many and, more important, encouraging much more feedback from and interaction among that many. For example, you might socialize your plan to replace Office 2010 with Office 365 by posting this information on the company blog and asking employees to weigh in with comments and suggestions, even alternatives. In the past, the IT organization would just make this decision and implement it.

I'm now working through our new smartphone/tablet/personal device policy, and it's clearly a high-touch, high-feel subject. In the past, my team would weigh the options, consider the overall business case and value drivers, and set a policy that we would then implement. But the past dealt with cell phones and laptops. With consumer devices, most employees have a much stronger opinion. Rather than come to us, the IT experts, for advice ("Which home PC would you suggest I buy?"), employees are now coming to us with advice ("The company should issue everyone iPhones, as I've found that they're the best smartphones on the planet.").

Not only does socializing involve a fairly broad audience (socializing with your staff doesn't count), but it also implies true interaction. And with that interaction comes the expectation that the mobile device approach our company ultimately will take won't necessarily be the one my IT team would lay out if we were (no pun intended) left to our own devices.

We will start the process at the top. I will send a summary of the initial plan to our CEO, and I will then present it at our next senior leadership meeting--not as a fait accompli, but as an idea. I will provide all of the answers to their questions. Members of the leadership team will chat about the idea, and eventually share it with their direct reports and ask them for feedback. Much of that feedback will come in the form of questions, which my team will answer, and I'll communicate those answers back to the broader management team.

This cycle will continue for a few iterations, before we open the discussion to employees and begin to zero in on the end point.

The Big But

This all may seem like an exercise in bureaucracy and CYA, but I have no doubt that the socializing process will produce a much easier implementation. But … and this is a big but: If the socializing process morphs into consensus-building, we'll have a huge problem, because there's no chance everyone will agree on what to do with smartphones, tablets, and other personally owned devices. At some point, our IT organization will have to make a decision based on our expertise, a decision that will be unpopular with some, even many, employees.

In the past, our IT organization's approach was to get our hands on everything and manage the heck out of it. We negotiated cellular contracts, locked down rate plans, set policy on our BlackBerry Enterprise Servers, centralized billing and chargebacks, and monitored expenses. I slept very well at night.

Adoption of personally owned, corporately enabled devices is very different. Centralized control will be expensive and will stifle the productivity benefits these new devices have to offer. There's no right answer, but if socializing means coming to a collective agreement, we may be a BlackBerry customer for much longer than I thought.

InformationWeek: Sept. 3, 2012 Issue