The recent media frenzy over the latest social media offerings introduced at SXSW last week demonstrates that collaboration is one of the app themes for 2011. This isn’t the first time collaboration software has been the “next big thing’” I remember back in the early 90’s when computer-supported work applications were all the rage (remember when “Lotus Notes” was first rolled out). Organizations threw a lot of money and resources at early collaboration systems but many were failures from the beginning.
The failure of many early collaboration systems to catch on was perplexing because software packages for individuals and organizations were doing well. What was it about developing software for groups that made it so different from developing software for individuals and organizations?
In 1994, Dr. Grudin (a computer scientist from the University of California) published an article that answered that question with the simple observation that groups were just different from individuals and organizations. How they are different is explained in his eight challenges for developers:
- Who Does the Work and Who Gets the Benefits. Ideally the labor in operating and maintaining the groupware application must be roughly equal among the group members. In reality this is rarely the case. Consider a project management application where the team members are required to update it regularly with progress reports, performance data, and other data. A good deal of the team member’s team is compiling information and feeding the system while the project manager just has to spend a minimal amount of time reading reports the system generates. The team member sees only a burden from the software and soon starts to avoid doing this extra work which leads to poor reports causing the Project Manager to quit relying on the system for information. Soon, no one is using software.
- Critical Mass of Users. The collaboration software field is filled with a number of different platforms for collaboration. Many offer similar features and each has its enthusiastic community of supporters. In large government agencies you can see several collaboration systems in various pockets of the organization that don’t communicate outside of their pocket. Ironically the systems that exist to promote collaboration often end up promoting organizational silos as the various groups argue that their system is the best solution.
- Social, Political, and Motivational Factors. Dr. Grudin gives a great example of this challenge when he describes the failure of meeting management software. It assigned meeting rooms based on priority but quickly became useless because no one wanted to admit that their meeting was anything but “high priority.” As Dr. Grudin explains, collaboration software can only model a rational workplace but actual workplaces are much more complex due to organizational culture.
- Exception Handling. We rarely work the exact way that is described in our work processes. Collaboration software built only based on the documented office procedures is seen as too rigid and not able to handle the flexibility required frequently at work. Just think of how often you don’t have a typical day at work and have to improvise a work solution. Now, imagine trying to program that into software.
- Decreasing the Communication and Coordination Load. Organizations are designed to reduce the amount of communication and coordination needed to do the job. How many times have you said that you could get more done if you were not interrupted so often? Of these interruptions, how many were due to email, phone calls, a colleague stopping by to talk, etc.? Sometimes you can over-collaborate and this often is the result of poorly-designed groupware.
- Hard to Evaluate Groupware. It is difficult to test groupware because the group dynamics are so hard to replicate. It can take several weeks of careful observation to fully understood how a group works and software designers just don’t have the time or expertise to fully evaluate how their software will aid in collaboration. Often the groupware vendor blames this on poor user training and will continue the same type of software with better tutorials and help aids but never realizing that the fundamental problem is that people just don’t like collaborating the way the software is forcing them to collaborate.
- Intuitive Decision Making. Because of the nature of our work we often have to make decisions based on little evidence and thus we rely heavily on our intuition. Groupware applications rarely support intuitive decision making but rather force users to input great amounts of data so that a fully-reasoned decision can be made. Often we do not have all of the data and a decision must be made quickly so we abandon the groupware application to use a simple spreadsheet or other individual application to support our intuition.
- Managing Acceptance of the Groupware. Too often I have seen a collaboration solution launched where the users are expected to adapt themselves to how the software works rather than the software adapting to the way the group works. There is a particular system at my work which is universally despised because it practically handcuffs a group of users to a cumbersome and protracted painful process. I’ve only used the system once but that was enough for me to avoid ever having even to click on the program icon.
Despite these principles being over sixteen-years old I still see the same mistakes being repeated in today’s Web 2.0 collaboration tools. I also see where companies have put these principles into practice and have made great collaboration software that has endured and grown in popularity. I fully suspect that Google engineers must have memorized these principles when they developed their Google Docs system. You can also see these principles at work in the various products from 37Signals and Zoho.
I leave a final exercise for the reader: how many of these principles does SharePoint violate (if any)? Or does SharePoint violate new principles of collaboration software?
Grudin, J. (1994). Groupware and Social Dynamics: Eight Challenges for Developers. Retrieved at http://research.microsoft.com/en-us/um/people/jgrudin/past/papers/cacm94/cacm94.html.
So where do you see collaboration, despite all the potential pitfalls, aiding in delivering Acquisition 2.0? Shold collaboration tools be considered SaaS or integrated into the PaaS?
@Sandy – Grudin suggests that collaboration features be built into existing software rather than be a stand-alone application if you want higher user adoption. Thus, I would suggest integration into the PaaS so that all of the software that is part of the platform have that collaboration component.
Jean-Paul – I am surprised by Google’s action because they usually do a better job in following Grudin’s principles. It is also surprising because of Google’s vast database of user actions and their ability to mine that data. Interesting proof that groupware is hard to evaluate because of group dynamics.
I especially like #6. I’d also add that it’s hard to advocate for the nuances of good collaboration software. I think those little differences are key but hard to explain
@Steve: When I read your comment I was struck by the fact that there is a field of communication study devoted to small group communication and problem solving. I wonder why those findings are not used in designing groupware.
Great reference. Tools that allow remote and asynchratic communication are critical today but still are tools that aid not replace people’s wants and needs. The core lesson is to undertstand organizational, group, and individual needs before choosing apporpriate tools.
Great reference – just went over “collaboration failure loop” as well as critical success factors here: https://www.govloop.com/forum/topics/ckos-information-architecture?xg_source=activity
Your list points to an overall failure of user-centered design (square pegs and round holes) – excellent references thank you!
I think Sharepoint is an excellent collaboration tool. The most important part of implementing such a comprehensive collaboration tool is Project Planning. Defining the project goals and objectives, soliciting requirements from stakeholders and implement features and functions using in an agile/iterative way so users can adapt, use and provide feedback.
If the collaboration tool does not work, go back to the stakeholder requirements and double check that you have met the needs, if not, add the need to the next iteration.
For CRM and other collaboration tools, I like Zoho because its affordable, comprehensive and it has APIs that allow you to connect to different systems.
Carlos V. Roman
Businesses rely on the content they own, from contract files, to personal records, to content that may be accessed, gathered, and used from the various web sources. Collaboration tools are ,maturing to serve as intuitive mechanisms to identify to the users content and projects that could be related to their efforts. To accomplish this an information architecture must exist that allows for algorithms to suggest to the user the possible relationships. That is where efforts such as OSERA align with collaboration tools to make possible Acquistion 2.0 platforms based on Collaboration tools.
The trend has been that social media tools are merging with collaboration platforms to offer the users more virtual water coolers. Users can dial into and use many transport mechanisms to both inform and to be be informed. There is a The Federal Acquisition Service had great success in using a collaboration tool that stacked on top of the implemented content management system. The tool used was simple and more departmental, the added value was great in how it enabled the users to manage the content and workflow of their projects. The growth curve in use of the tool was exponential.
Hi Sandy, I have been looking into Acquisition 2.0 platforms so that we can coordinate the posting on Public Works bids on PublicWorksAgency.com.
Do you have names of those platforms?
I do not have a list. Currently I am exploring the potential of the https://max.omb.gov/maxportal/
I have used the new SD facility to collaborate on work in real time. As others have stated, if the tool has the hooks and handles, open source, API to allow it to be stacked on top of the content engine and sued with other utilities, Cloud Services or legacy apps, then it may qualify to serve as a platform to develop integrated communities of interest. I suggest that the required next step is to develop a pilot with a Service Line Manager to detail the business needs to be met.