It goes without saying that people prefer to read through a quick list over studying a lengthy manual. With any new technology deployment, they expect the shortest path to get them up and running. You advise them that rolling out any technology should be a carefully planned exercise involving stakeholder discussions, testing, and clear alignment to business objectives -- and yet people want a list. The shortest path. Such is the conversation around enterprise collaboration.

The reality is that you probably already have aspects of what will become your strategy in play today. SharePoint, for example, provides much of what your end users want and need. But people want brand names. They see all of these cool consumer tools and flashy ad campaigns and they want it for themselves. They assume everything should look and work like the latest consumer-based platforms -- and to some degree, the platforms we use in the enterprise *should* look and work like the consumer tools we use for our personal collaboration. But use of "collaboration tools inside the enterprise" does not equal "enterprise collaboration tools." The former are things like Twitter, Facebook, LinkedIn, and Google+ -- great tools for building out your personal and professional relationships may not be scalable, compliant, transparent, or supportable in the corporate world.

People really like lists. "What are the 5 things I should be doing to improve the productivity of my team?" or "What are the top 10 strategies for gaining measurable business impact out of SharePoint with minimal effort?"

So here, in a nutshell, is what I tell people on how to begin defining their enterprise collaboration strategy:

Start the conversation inside your organization.
Start developing a simple message around the topic, defining what collaboration means inside of *your* organization. What are the core tenets of collaboration? What are the business activities you want to improve? What features have you seen elsewhere that you believe will positively impact your business? What is the culture of your organization, and what are people already doing vs. what would be new to them? This discovery process is an important part of your planning process, as you may uncover requirements or attitudes which may propel your effort forward, or curb your enthusiasm.

Develop a shared understanding of what the business is trying to achieve.
I like to think of the discovery process as one giant whiteboarding session where no idea is a bad idea -- just get it all out in the open. Understand the relationships between what individuals, teams, and business units are trying to accomplish -- and the potential impacts one requirement may have on others. For example, you want to break down the content / information silos, but you can't do so without first understanding the rules, the compliance, privacy and security implications. I like to think of this as the "normalization" process, which is just a large, transparent use case mapping activity.

Define the metrics by which you will measure success.
Talk about metrics before we've even decided on the technical solutions to be deployed? You bet. Because your focus at this point should still be on the business issues to be resolved, not yet on the technology to be deployed….even if you know its going to be SharePoint. There's nothing wrong with talking generically about certain features, because that's how we sometimes define and communicate our requirements -- through the lens of the features we know we need. Just be careful to not get caught up in all of the constraints of the technology, and focus instead on the business needs.

Outline the engagement.
Who are the stakeholders? What will be the key roles and responsibilities as you move forward? I always encourage people to look to their existing project management methodology for guidance. Most companies have an established methodology that end users and executives alike know, are used to, and can work within to define requirements, deliverables, and roles to move a project from beginning to end. These methodologies are designed to garner both bottom-up and top-down support. Use it to outline the high-level effort, and refine it as you begin to make technical decisions.

Identify the right technology(ies).
Notice how this one is at the end? That's intentional. Technology is largely binary -- it fills your requirements, or it doesn't. It has the features, or it doesn't. Yes yes, I know its not that simple, so don't bother your emails to tell me how complex technology is. People wanted a list, and this is the way I advise people to approach the problem -- with eyes wide open, and a clear path to business alignment.

This is not a complete methodology, just a general approach. But hey, it's a Top 5 List which everyone loves.

As with any "best practices" you should refine this model to better match your own internal processes and any established project management methodologies in place today. What this approach does well is prepare you for the inevitable ROI discussion. You need to begin thinking about the value add of your enterprise social collaboration strategy so that you can readily answer the questions when your CIO comes knocking.

Here at Beezy, we've deployed our solutions to some of the largest SharePoint environments in the world, so we understand first-hand the importance of planning. Not convinced? Give us an hour, and we'd be happy to walk you through our solution and several customer examples. Contact us to schedule your demo today.