Blogs

People prefer lists over lengthy manuals. 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. What "exactly" should I be doing? Such is the conversation around the latest social collaboration hype.

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, IMO 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.

But people really like those lists. "What are the 5 things I should be doing to move my organization toward the cloud?" or "What are the top 10 strategies for optimizing my BYOD strategy for the consumerization of IT fanatics in my org?" (not sure that last one makes sense, but it is rife with buzzwords).

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

1. Start the conversation inside your organization.
   Start developing a simple message around the topic, defining what social collaboration means inside of *your* organization. What are the core tenets of social 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.
    
2. 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.
    
3. 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.
    
4. 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.
    
5. Identify the right technology(ies).
   Notice how this one is waaaay 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 internal processes and PM methodologies. But 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.