Bill's Notebook

Does this look like your typical day as a local, state, or Federal worker?

• 31% of your work day is made up of purely ad-hoc, never happens the same way twice tasks
• 30% of your work revolves around consistent, defined goals but various ways to achieve those goals
• 20% of your work involves documented and managed tasks that are not automated
• 17% of your work is automated but there are numerous exceptions to the automated processes
• 9% of your work is fully automated and there are no ways to change the process (Fischer, 2011, p. 84)

Except for a very few exceptions, every government worker is a knowledge worker because they deal with constantly varying situations that we package into cases. In general, we may deal with specific subject areas and perform repeatable functions but the actual execution of this work will differ greatly from case to case. For example, when I was a paralegal/investigator for a public defender’s office, I helped on numerous assault cases. We had a specific process for interviewing the client, preparing the pleadings, assembling the evidence, and presenting the case. But the facts of the case were always different.

One case was about an assault by a drunken student on an equally drunk off-duty policeman. Another case was a domestic violence issue while a third involved a store employee who tackled a complaining customer. For each case, the kind of pleadings filed, how I conducted the investigation, and so on would differ based on the specific events in that case. You really didn’t know what was going to happen from day to day so it was difficult to determine routines beforehand.

This is why I don’t believe that the best way to improve government work is to start imposing Six Sigma and Lean processes onto government employees. Six Sigma and Lean are great methods if you are talking about repeatable processes that have clear paths and outcomes. But as the above statistics demonstrate, less than 10% of a knowledge worker’s day will benefit from traditional business process management techniques.

On the other hand, traditional case management as practiced by many government workers has many problems. Most government offices have overwhelming case loads, there are conflicting rules and procedures imposed by the top management, and the current support systems cannot easily handle the many exceptions that occur frequently (Swenson, 2010, pp. 10-24). What is needed is a way that allows for the great variation in knowledge work but makes that knowledge work more efficient and effective. I believe that the newly emerging management concept of Adaptive Case Management (ACM) is the answer along with its closely-allied discipline of Social Business Process Management (SBPM) (Fischer, 2011).

ACM is still evolving but there are several core elements. First, instead of being based on the principles of scientific management/Taylorism, it revolves around modern knowledge work. This means that ACM is designed to deal with change and ad-hoc processes as a case is being processed. Second, processes are not formalized and designed up front but are developed as the knowledge worker continues to see the same issue in a number of cases. Third, rules and regulations operate more like guardrails that constrain the actions taken in a case. The fourth element is that the knowledge workers rely heavily on a community-built template library and body of knowledge that is built collaboratively in the organization.

This is why ACM relies so heavily on social networking in the form of SBPM. In traditional business process modeling, discovering what processes exist and modeling these processes were done first and then the knowledge workers were expected to follow the newly-established processes until the weight of exceptions demonstrated that the new processes needed to be modified. Under SBPM, process discovery and modeling occurs as knowledge workers work on cases and share their experiences with each other. Thus, there is a great deal of variation at first in handling cases but as the knowledge workers gain more experience, they collaboratively develop best practices that can easily be modified when exceptions occur.

I have just given the briefest overview of these two new management concepts but I am greatly excited by the potential to reform government work for the better. There are numerous case studies in Taming the Unpredictable including how one local government agency used ACM for better customer service in its case management processes. Much of ACM and SBPM makes intuitive sense and should be especially attractive to those who argue we need more knowledge sharing and collaboration in our offices.

(Disclaimer: All opinions in this posting are my personal thoughts and do not reflect upon my employers or any organizations I belong to.)

References:
Fischer, L. (editor) (2011). Taming the unpredictable: Real-world adaptive case management: Case studies and practical guidance. Lighthouse Point, FL: Future Strategies, Inc.

Fischer, L. (editor) (2011). Social BPM: Work, planning, and collaboration under the impact of social technology. Lighthouse Point, FL: Future Strategies, Inc.

Swenson, K. D. (editor) (2010). Mastering the unpredictable: How adaptive case management will revolutionize the way that knowledge workers get things done. Tampa, FL: Meghan-Kiffer Press.

Additional Resources:
Law and Order: How Adaptive Case Management Serves the Public Good – http://community.global360.com/bpm_practitioner/b/weblog/archive/2011/08/11/law-and-order-how-adaptive-case-management-serves-the-public-good.aspx

Simplify Your Work Life: Adaptive Case Management – http://i-sight.com/tech/adaptive-case-management/

The Future of Adaptive Case Management – http://www.industryweek.com/articles/the_future_of_adaptive_case_management_22981.aspx

What is Adaptive Case Management? – http://www.cmswire.com/cms/enterprise-cms/what-is-adaptive-case-management-008277.php

Adaptive case management: New tools for doing more of what we do best – http://www.kmworld.com/Articles/Editorial/Feature/Adaptive-case-management-New-tools-for-doing-more-of-what-we-do-best-74486.aspx

What Could Cause Adaptive Case Management to Fail in 2011 – http://blog.actionbase.com/what-could-cause-adaptive-case-management-to-fail-in-2011

From an early age, I have never liked the observation that something is complex. It usually meant that person is just resigning themselves to never understanding the problem. I couldn’t stand this defeatist attitude and have spent most of my life trying to devise ways to tackle complex problems including the aptly-named “wicked problems.” Even though I may never find the solution to the P versus NP Problem, it has taught me a great deal about problem solving in general.

So, what do we mean when say a problem is complex? According to Dr. Melanie Mitchell, there are nine definitions for complex as used by complexity theorists. These definitions range from “complex as a matter of size” to “complex as a degree of hierarchy” to “complex as a measure of algorithmic information content” (pp. 96-111). I tend to think of complexity in terms of systems theory in which you have a number of discrete components with numerous feedback loops and many variables that are hidden within the system processes.

A good example of a complex system is the American economy. There are many discrete components in the forms of companies, consumers, banks, regulatory agencies, etc. all passing information to each other and reacting to that information. Attempts to model the American economy range from the simple macroeconomic diagrams in textbooks to detailed microeconomic equations that requires years of mathematical study to even understand. Yet these models, no matter how detailed, cannot fully describe and fully predict how the American economy operates.

If you accept my definition of complexity then you can see how the next concept describes why complex problems are hard to solve. We have difficulty in solving complex problems because our observation of the problem is hindered, we cannot fully understand the problem, our decision-making processes are flawed, or we cannot act appropriately in confronting the problem. If any of the difficulties I mentioned sound familiar it is because I am describing the four components of the “OODA Loop.”

The Observe-Orient-Decide-Act Loop (OODA) was created by Colonel John Boyd who was a fighter pilot and scholar in military strategy. This concept has been adopted both by the U.S. military and championed by such business experts as Tom Peters. As the diagram below demonstrates, a person, team, or an organization observes a situation along with other inputs. Based on the observations and several internal factors, the subject attempts to orient themselves or understand the unfolding situation. Based on that understanding, the subject then makes a decision and acts upon that decision. Throughout the OODA Loop, there are several feedback channels that make the entire process nonlinear.

Colonel Boyd explained that the use of the OODA Loop was to travel through the Loop faster than your opponent. You present confusing and ambiguous information to your opponent so that they have difficulty orienting themselves and thus are slower to decide and act. Essentially, you want to go through your own OODA Loop faster than your opponent does so that they start falling behind and then are paralyzed by their inability to analyze the situation. Time is the key factor in OODA Loops.

The OODA Loop is why I think complex problems are so difficult to solve. Consider the five components of the OODA Loop as it applies to your personal abilities or the abilities of your team/organization:

• Observe: This is the beginning of the Loop and also feeds into another iteration of the Loop. If your observational abilities are hindered or you just cannot observe all parts of the unfolding situation then you are working with incomplete information. History is replete with examples where disasters occurred because of the lack of key information.
• Orient: This is where you/the team/the organization takes in the new information and pairs it with your previous knowledge, cultural traditions, and other internal factors that influence how you process and analyze information. So, even if you are able to observe the entire unfolding situation, your internal abilities to process and analyze this information can prevent you from fully understanding what is happening.
• Decide: This relates to your ability to generate hypothesis about the situation and possible responses. There is the common “paralysis by analysis” which hinders decision making because you are still trying to orient yourself to the situation. Or, even if the organization has a good understanding of the situation, decision processes may be so cumbersome that you cannot make a decision in time to act on the situation.
• Act: You may not have the resources to act promptly and/or appropriately. Your understanding of the situation may have led to a flawed decision that forces an invalid response to the situation. You do not have the proper feedback mechanism built in your action to determine how your act affected the unfolding situation.
• Feedback: As you go through the OODA Loop, you are constantly generating and receiving feedback from your current iteration and previous iterations. Without good feedback design, your own actions can contribute to the ambiguity of the situation. This is especially true of wicked problems where there is no consensus on the actual shape of the problem and your actions can drastically morph the problem into a completely new problem.

The good news here is that you can also use the OODA Loop to better your abilities to handle complex problems. Use the five components as a checklist for improving your (or your organization’s) processes in handling complex problems.

For example: how well do you observe? How good is your organization at collecting and disseminating information internally? Do your people have the necessary prior knowledge and analysis skills to properly orient themselves when new observations come in? How robust and quick is your team’s decision-making skills? What barriers can you remove so that you can act faster? What can you do to improve your feedback mechanisms?

Government is going to face more complex problems especially in a climate of reduced budgets and increasing responsibilities. All government employees at all levels need to sharpen their problem-solving skills so that we are more innovative and can better tackle the looming wicked problems that face the nation. Whether you accept my suggestion to use the OODA Loop or come up with your own problem solving method, the process of thinking about complex problems is a great way to sharpen your problem solving skills.

Reference:
Mitchell, M. (2009). Complexity: A guided tour. New York: Oxford University Press.

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.

Great story on how network analysis can explain the 2008 collapse.  Look at the four network diagrams in the middle of the article.  You can see the various sectors of the economy gradually merge together.  The most alarming trend is how real estate went from an almost isolated sector to being the center of the combined networks.  Graphic proof of how the growing interdependence between the sectors fueled by increasingly exotic investment instruments short-circuited the regulatory safeguards of  the economy.

Doing a lot of research on process intelligence and project intelligence. I’ve started pages devoted to these subjects. Not many resources at the moment but I expect this to change once word starts to spread.

Nancy Dixon (author of one of the best books on communities of practice – CompanyCommand) has a great blog post about how NASA used conversation to capture knowledge gained from currently canceled Constellation program.  She describes how she helped NASA develop a knowledge capture strategy by working with NASA employees and other thought leaders in knowledge management.  Some excellent stuff here and I hope she formalizes the process into a book.

Two interesting articles about organizational culture in the latest issue of the “Journal of Organizational Change Management.”  The first article is a cultural analysis of organizational memory and its role in organizational change while the second article describes how organizational memory can hinder learning a new technology.

In the first article, McCabe gives a more detailed description of organizational culture as a collection of shared memories.  These memories can contradict each other or just be ambiguous about past organizational events but, woven together, these memories form a dynamic and conflicting culture for the organization.  McCabe disputes the common belief of many management theorists that the past can be erased in favor of the new reality because the past always blocks change.  Organizational memory is more complex than that because some memories can help facilitate change while other aspects resist change.  McCabe concludes by stating that organizational memory cannot be managed as part of the change process but must be accounted for.

McCabe’s article illuminates the findings in the second article by Becker.  The second article deals with the process of acquiring new technology in an organization.  As Becker explains, for employees to adopt a new technology they must unlearn the old technology.  They do this through releasing mental models of the workings of the old technology and create mental models of how the new technology works.  Memories of past change efforts can hinder the process of unlearning if it promotes fear and anxiety among the employees.  Becker does not have any specific remedies for dealing with organizational memory and unlearning but she does argue that further research is necessary to fully understand the unlearning process.

The relevance to Gov 2.0 is clear.  Many agencies have long and painful memories of past change efforts that have been woven into the current culture.  Gov 2.0 advocates must understand and acknowledge the past while developing strategies to alleviate the fear that will prevent government employees from unlearning the current way things are done in favor of making government transparent, open, and engaging.  Gov 2.0 advocates must take the positive aspects of the past and use those events to counter the negative past events while realizing that culture cannot be fully controlled.

References:

Becker, K. (2010). Facilitating unlearning during implementation of new technology. Journal of Organizational Change Management, 23:3. 251-268.

McCabe, D. (2010). Taking the long view: A cultural analysis of memory as resisting and facilitating organizational change. Journal of Organizational Change Management, 23:3. 230-250.

“Mr. McGuire: I want to say one word to you. Just one word.
Benjamin: Yes, sir.
Mr. McGuire: Are you listening?
Benjamin: Yes, I am.
Mr. McGuire: Plastics.
Benjamin: Just how do you mean that, sir?”
The Graduate – 1967

In the late 60s, plastics may have been the growth industry but, according to Mike Loukides at O’Reilly Radar, the ability to work with data is the new growth industry.