Who is Responsible for Collaboration and Can They Answer Yes to These questions?

Business Before TechnologyMan2tech

I do not believe many would argue that effective collaboration is beneficial.  In fact, a July 2012 study by McKinsey & Co. insists that social networks, for example, can save organizations billions of dollars per year in time spent managing email, communicating internally and searching for information.  However, recent Forrester research found widespread underutilization of the social tools that organizations have invested in, with 64% of companies reporting they realized few, if any, benefits from the investment. Worse, only 8% of employees actually use enterprise social collaboration software more than once a week.  So what is the problem?

The answer to this paradox lies in one of the most important and most underused precepts: mapping technologies to business processes.  (Included in The Most Overlooked Construct For Successful Collaboration Adoption.)  Tying collaboration tools to business processes is essential in order to:

1)  Measure the impact of the tools – if we have not defined the goal, there is no way to measure it.

2)  Increase adoption – Accenture’s David Blitz called it, Converged Collaboration: where “the collaboration technology isn’t layered onto the process; it has become the process.”  Adoption runs parallel to the usefulness of the tools.  (See Full article here)

So why is tying collaboration tools to business goals and processes so disquieting?  First, we need to ask the questions in a different order.  Buying tools and then trying to shove them in to a business processes, is a quick way to create the proverbial shelfware….or invoke the idiom, “putting the cart before the horse.”

Ok, so let’s start by looking at business processes.  First question – Which team does the looking?

If you are an organization large enough to support a collaboration team of engagement specialists; or, are comprised of technologically progressive employees, this is likely not an issue.  However, for the remaining 99% of companies it is.  Many times, the IT department is left with the responsibility to select, deploy and train on collaboration tools.

Not for lack of desire; but, our IT departments are still mostly service fulfillment.  If you look at the history of IT as a department, their goals were usually to provide and manage infrastructure and were measured on on KPI’s like up-time and security.  Microsoft Office, for example, was applied to job roles as each department saw fit.  It was IT’s job to provide single sign or the correct desktop image.  Additionally, many IT personnel resources are diminishing.  We do not expect the accounting department to understand all the business processes of marketing – we should not expect our IT partners to understand them either.

So, it must be the line of business’ responsibility, right?!  Let’s see…

Can you or your favorite line of business manager (including IT) answer Yes to the following questions?

  • Do you understand the collaboration tool options in the marketplace?
  • Do you have a clear understanding of where and how collaboration tools could effectively impact business goals?
  • Are you savvy in successful change management programs to promote adoption of selected collaboration tools?
  • Can you measure the impact of implementing collaboration tools?
  • Do you have the time or resources to head a full-time initiative researching collaboration tools and ensuring effective implementation?

Unfortunately, most teams cannot answer Yes.  The business units are not product experts; the IT departments are not Learn More M4process experts; and neither are likely adept at employee engagement and quantifying business impact.  However, both teams must be involved in any decision to acquire and implement new tools and, responsible for the project’s success.   If teams cannot answer Yes to these questions, I recommend finding a consulting partner that can help shape the path.  These questions are answered with the M4 adoption program: addressing business processes and people before selecting tools; and, bridging the gap between IT and other lines of business.

 

Leave a Reply

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