Bill's Notebook

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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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 system is forcing them to collaborate.
7. 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.
8. 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?

Reference:

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.

As I wrote in a earlier posting, I coined the term collaborgagement while attending a session at Content.gov. John Newton (Alfresco’s CTO) commented that the next generation of enterprise IT tools need to serve the middle of the enterprise – the domain of the knowledge workers. These tools need to support collaboration, knowledge management, and just-in-time sharing of expertise. Even so, collaboration/knowledge management software doesn’t automatically empower knowledge workers. There has to be more than just new tools.

Collaboration is important but it is not sufficient. Nicholas Charney noted this in a great posting where he questioned the value of collaboration as it was currently practiced in organizations. I commented that a tangible product from the collaboration would make the process better but I am becoming more convinced that even that is not enough. What is needed is something that would continue the benefits of collaboration between the collaboration sessions. A way of engaging the person’s thoughts and focusing those thoughts on the collaboration work even when the person is working alone. A process that I call collaborgagement. Not just a combination of collaboration and engagement but a process that is synergistic.

The foundation of collaborgagement is the mental model. The mental model has been variously defined by different fields but the consensus seems to be that mental models are “deeply ingrained assumptions, generalizations, or even pictures or images that influence how we understand the world and how we take action” (Wind and Crook, 2005). Individuals have mental models but so do teams and departments. The purpose of the mental model is to make sense of various aspects of our lives including our work. Mental models take a great deal of effort to build but the benefit is, that once built, they reduce our thinking load.

For example, researchers have found that expert chess players actually think less than novice chess players because the expert chess player can focus on several pieces at once and perceive patterns of board arrangements. The novice chess player has to focus on separate pieces and build the pattern from the individual pieces. The expert chess player has a library of mental models they can consult that makes them better players because they can “look up” the answer to a chess problem while a novice is still calculating the problem.

The same process can be seen in everyday life. Think of how you learned to drive. Remember all the steps you had to master to start the car, put it in drive, and begin your journey. Repetition and observation helped you build a mental model so that driving almost becomes an automatic process requiring very little conscious thinking.

The challenge is that we rely on our mental models so much that we strenuously resist changing or discarding our existing models. This goes for team mental models as well as individual mental models. But our changing world requires that we change our mental models or they quickly lose their benefit and can even harm us in the new realities we face. We need a process of engaging peoples’ attention at the level of their mental models and then collaborate together to help explore current mental models and modify or even replace these mental models on an individual and team level. This is the purpose of collaborgagement.

There are probably several methods for examining current mental models and altering them but I like the process Wind and Crook (2005) outline in their book The Power of Impossible Thinking:

1. Understand the power and limits of mental models.
2. Test the relevance of your mental models against the changing environment, generate new models and develop an integrated portfolio of models.
3. Overcome inhibitors to change by reshaping infrastructure and the thinking of others.
4. Transform your world by acting quickly upon the new models, continuously experimenting and applying a process for assessing and strengthening your models. (p. xxiv)

With Wind and Crook’s (2005) process in mind this is how collaborgagment would work:

1. Before a team meeting the individual members examine their existing mental models that relate to the topic of the meeting. The team member may want to blog, mind map, or similar tool to help him or her to surface the mental models and produce it in a tangible form.
2. During the team meeting the individual members display their mental models. Then the team works together to surface the team mental models in a tangible form.
3. The team then examines the new reality of the topic and lists the characteristics. The goal of this phase is to come to a consensus about the new reality.
4. After a consensus has been reached, the team compares the current team mental model to the new reality. Does the team mental model need revising or is a completely new team mental model needed? The team works to determine the revisions or constructs the new mental model.
5. After the team meeting the individual members go on their own to reflect on the consensus about the new reality and how their current mental models compare to the new reality. The member then revises their existing mental models or constructs new mental models that reflect both the new reality and the team mental model.

What is important about this process is that it engages people on a deeper level than what usually happens in change efforts. I have been to plenty of meetings where great ideas and energy has been generated but it quickly dissipates once the meeting is over. For deep and sustainable change to happen you have to engage people at a fundamental level and produce collaboration that carries on ever after the meeting is over. I believe that starting at the mental model level is the best way to produce lasting transformative change.

Reference:
Wind, Y., & Crook, C. (2005). The power of impossible thinking: Transform the business of your life and the life of your business. Upper Saddle River, NJ: Wharton School Publishing.

Previous Posts on Collaboration and Engagement:
Without Engagement Gov 2.0 Will Fail
The Goal of Collaboration: Navigating the Network of Idea Spaces

I attended the Content.gov seminar in DC today. The seminar was hosted by Alfresco and of course revolved around how this open-source enterprise content management tool can improve content management for government agencies. I’ve experimented with it a bit and think it is a good product.

What I took away from the conference was some ideas from Alfresco’s CTO, John Newton. He argues that enterprise IT has essentially been on hold since 2000 while consumer IT (Facebook, Twitter, etc.) has been on fire all throughout the first decade of the 21st century. Employees are demanding enterprise versions of what they use in their daily lives to connect and collaborate with their families. Not an original thought but a good summary of what is about to hit enterprise IT.

What was original and started me thinking was his later point that enterprise IT needs to build systems of engagement. That is, applications that focuses on the middle of the enterprise where the knowledge workers are. He states that we don’t need anymore applications for the frontline workers nor the top management because their needs are already met. I agree with the point about the top management but I am still not convinced about leaving out the frontline workers.

I do fully agree that the people in the middle of the enterprise do need better tools from enterprise IT. Tools that incorporate collaboration, knowledge sharing, and a whole host of activities under a new umbrella term that I just coined – collabogagement. A quick Google search shows that no one has used this term so I claim to be the first. In a future posting I will try to define it.

This is the workshop I attended on February 17th.  Amazing amount of great material in such a short time.  The final document (available in Word):

http://opengovdirective.pbworks.com/f/Final+Results+of+the+February+Open+Government+Directive+Workshop.doc