Why Do We Keep Trying to Stuff an Elephant Through the Soda Straw?
I just finished an interesting book by Torkel Klingberg, titled: The Overflowing Brain: Information Overload and the Limits of Working Memory. His observations and comments about “information flood and flow” got me thinking about how little attention is placed on audience by people who are crafting documents for the regulatory review agencies, like FDA.
Klingberg talks about the “infostress“ (a term credited to Dr. Neville Meyers at the Queensland University of Technology) that occurs when we are faced with trying to pass too much information though our brain. That is, we are trying to absorb more memory load than available memory capacity. Think of it as “mental bandwidth.” We all face this phenomenon at various times and in different ways. In our McCulley/Cuppan work, we are concerned with how scientific and technical documents may impact the mental bandwidth of the regulatory reader.
I see it time and time again where people working on documents keep throwing “information” as ill-defined heaps into documents. Heaps that may bear no connection or utility to the primary arguments or issues that the documents address. But since it was data the study generated: “let’s get it in the report, because you just never know if the regulatory reader may be interested in this data.” Sometimes heaps are built in an attempt to veil weaknesses in a study: “let’s make our study look better by the sheer volume of data and discussion we can put into this report.”
I see it time and time again, where review teams judge documents from their perspective, not the perspective of the reader. I have yet to encounter the thoughtful reviewer who judges a document with concerns for the regulatory reader’s ability to effectively manage and process all the information. Often a reviewer’s personal insight about the full set of information in a report is built up over months, perhaps years. They fail to account for the fact that their regulatory readers must process the same set of information in a matter of weeks or months.
I see it time and time again, where drug sponsors are indignant about certain questions or inquiries made by regulatory agencies. “Why are they asking that question? We gave them that information in Report XYZ.” Rather, the question that should be posed is, “What’s wrong with us? Why did we fail to account for how our key customer makes use of our documents and their ability to effectively process the information we provide to them?”
Somewhere along the line, we have to take pause and start thinking more about how people read complex technical documents and the limits of the regulatory reader’s mental bandwidth. We have to stop trying to stuff an elephant through a soda straw.
How long till you ride the wave…the Google Wave?
If you have not yet heard of Google Wave, then take note because Wave represents a concept that will soon alter the way you engage in your work. Google Wave is ultimately going to change the face of knowledge elicitation and collaborative authoring in every organization operating in the life sciences (other knowledge intensive industries too). The only question is when? When will this happen? I suspect early adopters will be trying out applications in the near term.
Here’s a link to a video introducing Google Wave.
Google Wave is also going to change aspects of every business that currently relies on communication and collaboration tools of any sort, even email will be transformed. More importantly, since this is a blog geared towards technical and scientific communicators, Google Wave is ultimately going to change how teams engage in knowledge elicitation and management and how writers/document owners collaborate with their subject-matter experts and reviewers.
Google Wave, with focused implementations, is going to supplant (because of significant new functionality) pretty much every planning and collaboration tool you may be using for the conduct of scientific work. Google Wave will certainly change the tools that technical and scientific writers use, and the way that they collaborate with their subject matter experts and reviewers. Here’s a video showing how Google Wave can be used to improve collaboration in the review/editing of a document.
So let’s get on with making review outcomes better
“Change is the only constant.”
A quote attributed to the Greek philosopher, Heraclitus. A quote that remains as real today as when made 2450 years ago. On the one hand, we say that change is inevitable. But on the other hand, all of us (well at least the vast majority of us) resist change. Change is rarely comfortable.
Making changes in business work practices? Now that is never comfortable. By work practices, I am referring to the what and how of engagement in particular tasks. Like how we choose to engage in the planning and drafting of a research report or participation in a round-table review of a research protocol.
Bringing about change in business work practices has never been the responsibility of individuals, rather it has been and remains the responsibility of management. Reliance on individuals to see the merits of change will not get the job done. A spin on the old saying goes: “You can manage the process so the horse gets to the water, but you cannot manage the practice of getting the horse to drink the water”. Managers have to not only be the initiators of change, but they have to be the facilitators, and owners as well, otherwise it will just never happen.
Philip in a recent post talks about how many of the work practices that inhibit effective knowledge management and collaboration are grounded in the classic Euro/North American education system. It is indeed hard, really hard to expunge deeply rooted “ways of working” from people. For instance, the ways of working to produce and review documents have become part of many personal belief systems. Belief systems that are not easy to change despite the great weight of evidence suggesting change is needed. We find that many people become incredibly emotional when we talk about changing how they approach knowledge sharing and document development. I want to stress here, incredibly emotional. At times such people take the suggested change in ways of working as an attack on their sense of professionalism.
We find that for people professionally driven to make scientific decisions predicated on a robust body of evidence, that this approach of presenting quantitative and qualitative information works equally well in getting them to make changes in their work practices.
Some reading this blog will be familiar with the change management tenets of leadership guru, John Kotter. Here’s a link to his personal web site. Great concepts that are proven effective in the real world. Concepts we try to follow when working on change projects in our McCulley/Cuppan consultancy. Kotter talks about how you must establish a sense of urgency. People must have a reason, and a really good one at that, for doing something different (an argument made by Philip in another post). Kotter suggests that 50 percent of change efforts fail, because they do not effectively set the stage for change.
To help us set the stage and provide people with the motivation to change, we try and collect meaningful data on work practices. A case in point is review, where we collect a variety of information on what people actually do (and do not do throughout the review process). We look at how they read a document, what focus they bring to the reading, what review remarks they make, how they make their remarks, how long it takes to complete a round of review, how review comments may or may not change as a draft document matures, and how a team engages in discourse during round-table review sessions. We then package up all of this information and share it with the organization in a workshop setting. We then ask participants for recommendations on what can be done to reinforce the strengths (if any) and what can be done to mitigate or eliminate the weaknesses uncovered in our analysis. The list can then be used by management as a reference guide to help redefine work practices and construct implementation methods .
