I’ve been thinking about the difference between implementing a collaboration application for business versus more traditional applications like ERP, CRM, etc. (insert other acronym here). I’ll try not to be biased but I believe that implementing an application like GroupSwim is different and easier. First, let’s list a couple of assumptions and my conclusions:
Assumption #1: The amount of archived/older information that people rely on for their day-to-day knowledge-based jobs is relatively small
Conclusion #1: The need for collaboration software to integrate with older documents and information stores is minor but often overblown. I know this flies in the face of tradition, but I think it is true. From what I’ve experienced, people use a small subset of documents, resources, etc. and do most of their work from their inbox and on specific documents that are part of their current plate of work. This isn’t necessarily a good thing but is reality; people aren’t accessing 1 year old plus documents very often. For example, if you are product manager, you probably do most of your work on current product specs, analysis, customer focus groups, etc.. If you are a sales person, you use a small set of documents (marketing collateral, emails you like to send, account plans, contracts, etc.) to find and close deals. The list goes on but you get it. So, I don’t think making every single document every created available to a new system is important. There is no doubt that there is a group of documents (training, in process files, etc.) that are important, but they can be added manually or integrated without trying to integrate everything.
Assumption #2: Collaborative work is dynamic and constantly changing
Conclusion #2: There are few examples of a “best” time to roll-out a collaborative solution. Employees are constantly collaborating on something so just get started. There are reasonable examples of where it makes sense. For example, if a group get reorganized, or a new project or process gets kicked off, etc., these are good times to start using a collaborative solution like GroupSwim. However, my conclusion is that now is as good a time as any to get started. I think that most “knowledge” work requires collaboration on an every day basis, so there is no time like the present to bite the bullet and get started.
Assumption #3: Collaboration is an ill-defined process at best
Conclusion #3: The change management and leadership required to make people collaborate differently is even more onerous than traditional systems. For example, when you implement a new CRM, ERP or whatever, your work process to get things done “must” change. You are essentially forced to modify the way you work whether you like or not based on the new system you must use. With a system like GroupSwim or other collaborative solutions, you can still use email and other means to get work done even though the outcome and process might suck. So, it is incumbent on a champion and other internal leaders to make sure people buy-in and use new collaborative tools like GroupSwim to change the they work. Eventually, they will get it and not require the oversight but it is critically important in the beginning to change habits.
Taking all three points into consideration, I think the collaboration implementations generally overestimate the need to integrate and deal with technical issues and underestimate the need for leadership and change management. It is always harder to change people’s work habits and soft skills versus changing a discrete process or operational system. What do you think?
Tags: ChangeManagement, collaboration, Implementation, Methodolgy, Software
July 3, 2008 at 10:14 am |
Jason,
Excellent summary and I couldn’t agree more. In my experience, item #3 was the failure point. Change management at the leadership level was far more difficult (in fact, it ended up terminal) than training the front lines to contribute best practices commonly/collaboratively.
In retrospect, here is what I think I observed. Leaders work long and hard to climb the ranks of corporate cronyism, and it usually isn’t mastery of job skills that get them there. As such, nothing is a greater threat to middle/upper management (the original implement for identifying and developing improvements) than abdicating control of genius generated by the lesser ranked to a collaborative system. Tell me if you’ve ever heard this, “I pay you to work, not think. Now get back to work.”
If acknowledged, well in advance, that any aspect of democratization is a potential threat to the structure of traditional corporate dictatorships, strategists can draft a strong plan for overcoming the resistance that has its roots in ignorance and fear. One incentive for managers/supervisors that I found was best recieved was reduced work load. In essence, if an employee complained that a change needed to be made to such and such, the retort could be “let me show you how you can fix that,” instead of “okay, I’ll put that on my list of things to do.”
Again, great write-up. The content here is king – but still democratic, a powerful combination.
Brian
July 3, 2008 at 11:14 am |
Hey Brian,
Thanks for the comment. I agree with you 100%. Your comment about reduced work load rings true. If you like at my Day 2 summary of Enterprise 2.0, one of the learnings is you MUST make work easier or reduce it for success. If you add a new system on top of everything else and not expect people to work differently, it will not work.
Jason