Sharepoint and Historical Dependence on Email: Why Outlook Hides Reasons that Make SharePoint Implementations Fail

Guest Author: Daniel Dunne

Here’s a typical path for a SharePoint implementation in your neighborhood:

The organization is distributed: there’s a large contingency of in-office information workers with a smaller, but mission critical, staff distributed in the field. The organization has a complete dependence on email and turns to SharePoint to enhance communication and reduce the email rat race. IT operation has some form of a VPN in place to enable the remote worker’s native Outlook client, and the SharePoint server is only visible from the VPN. Many organizational entities take hold and create powerful sites that organize team and project activities. The field staff, however, stubbornly resists and declines using SharePoint-based resources – for one silly but critically important reason: “I try to use those discussion boards and lists – but they’re too damn slow!” Implementation efforts eventually reach a glass ceiling of participation which never really reaches the potential that SharePoint has for the organization.

What’s happening?

The Outlook client’s native “Synchronize” technology is a novel and very powerful (credit to Microsoft) technology that has historically enabled remote users to work “virtually” anywhere, seemingly, seamlessly. (“While I’m sitting on my long plane ride, I can grind out 75 new email messages to my associates (YIKES!), then when I’m at the hotel I “send/receive” and all my messages!” Never mind that the VPN connections used for that synchronize was about 150Kbps.) Slow, jagged, and inconsistent VPN’s are masked by the outlook client’s robust ability to “send/receive” occasionally over very slow connections. Users don’t mind, much less recognize, that some VPN setups reduce Gigabit connections to less-than-dial-up speeds; you don’t know the difference if you only send/receive at a leisurely, occasional interval. Email, as an asynchronous communication, lets lazy IT operations get away with deficient VPN connectivity solutions.

Flash forward to SharePoint, a synchronous communication tool, that relies on a consistent and navigable HTTP connection between client and server. Connections that are poor, unreliable or inconsistent create negative perceptions with users that are very difficult overcome

What’s been done about this?

The typical approach is to invite in some sales demos for 3rd part SharePoint synchronizing utilities, (“let’s make this SharePoint thing do that same thing the Outlook client is doing!”)   There are many, MANY third party solutions for “synchronizing” sharepoint resources for offline users, but I think of this like people selling maps to avoid traffic jams.  They’re complex, you usually get lost trying to follow them, and you spend more in time and gas getting where you wanted to go, than if you’d taken the direct route in the first place.

And then there’s the Outlook client itself… in 2007 Microsoft created utilities in the outlook client to “synchronize” SharePoint document libraries and lists.  Outlook client-based synchronize approaches are operational, but disorienting to the casual user, (“Outlook is where I go to read email – it’s confusing to me to edit my proposal from within Outlook.”)  Besides, carrying redundant copies of SharePoint content on the exchange server doesn’t seem like a good use of resources.

And now’s there’s the groovy SharePoint Workspace 2010.  The exchange server will probably breathe a sigh of relief, but the user experience is still disorienting.  For its many layers of complexity and local resource consumption, you’ve got to really want to edit/contribute offline to master this solution.

What’s the right thing to do about this?

The right thing to do is to address the root cause – the unreliable VPN connection. This is not a security column, but there are many who can call an HTTPS secured resource strong enough to be internet facing in the first place, (get rid of the goofy VPN!) Either way, benchmark your VPN and go on safari to the places where the field operation goes, (the hotel, the airport, and especially: the client or customer locations!) to determine that your connectivity solution is ready for prime time, and garnishes the respect of new and uncertain users.

Guest Author: Daniel Dunne

Dan is a Mechanical Engineer who has a 20 year career in product development, including product design, (US Patent holder,) program management and consulting Mechanical CAD, PDM and PLM-related software implementations. Dan has lead SharePoint implementation teams (as a direct employee) in several different corporate environments, including his first which emerged from a server he setup under his desk in engineering. Dan has consistently championed and evangelized the user-driven SharePoint implementation as most aligned to Lean Methodologies and does everything he can to promote the Spirit of Continuous Improvement. Dan can be reached at [email protected]