More thoughts on the limited sophistication of documentation practices in the life sciences

I mentioned in this post that I consider the documentation practices for creation of regulatory submission documents in most pharma and medical device enterprises to rather unsophisticated. My position is largely driven by comparing observations of documentation practices to descriptions of varying levels of documentation maturity we have developed. Our descriptors have their roots in the work presented by Joann Hackos in her book: Managing Your Documentation Projects.

Like Hackos, our documentation practices-maturity model is a six point scale ranging from: Level 0 — Oblivious to Level 5 — Optimizing. My observations suggest that the vast majority of regulatory writing falls into the 2.5 range, which is between Rudimentary and Organized/Repeatable.
The Rudimentary documentation organization is one where the vast majority of effort is placed to ensure documentation consistency. All documents are generated utilizing well characterized templates. Document strategic review is largely absent as energy is applied to ensuring structural (that is, grammar and format) accuracy and consistency. Work practices are highly individualized and there is little application of meaningful estimating of document size or time lines.

The belief statements of organizations working at the rudimentary level include the following:

• All writers manage their own projects
• We would like to know more about our reading audience, but nobody takes the time to learn more….so we “suppose” what they want in our documents
• Our users are just like us…….I am a subject matter expert, so every other person educated like me will read documents just like I do
• We talk about what the data means, but we rarely talk about how to represent this meaning in our documents until we are into round table reviews
• We have little concern with how many rounds of review go into creating the final version of a document….we strongly endorse the credo “the end justifies the means”
• Planning document content before actually writing a report is just busy work
• We routinely reverse engineer document development timelines from the stated publication deadline and not from the scale and scope of the intended document
• We care what the customer thinks of our documents, but we do not use any organizationally applied quality standards. Standards are principally driven by teams and their senior reviewers
• File and forget–we do not take time to collectively reflect on documentation work practices practices

The belief statements of organizations working at the organized and repeatable level include the following:

• We have begun to study our document users but see little value in a concerted effort to collect information on how well our documents “satisfice” their needs
• We are surprised or even indignant when we get questions from our regulatory user looking for information that we included in our submission package
• The quality of our document project management is inconsistent, but we are okay with that because that is reality and each project is unique
• We do not see meaningful metrics beyond time for documentation projections…if we meet the deadline, then ways of working had to be good
• Nobody knows what others are doing in the process of review…the only way they know is via what may be discussed during a round table review
• We believe in our described “ways of working” until faced with unexpected situations, then we panic and call for “all hands on deck”
• We can easily get caught up in “process” at the expense of “product”

Now let’s contrast the above with belief statements of organizations working at the optimized level which include the following:

• We always engage in collaborative pre-writing planning of documents to make sure we fulfill strategic purpose of any given document
• We are thoroughly committed to understanding our document users and we work to systematically collect information from them
• We know how big a document will be even before we write it
• We always do end-of-project analysis to collect lessons learned and then disseminate this information across the organization
• We maintain a database of critical documentation work practice parameters and benchmark all documentation projects
• We recognize that accuracy and consistency are just the start of ensuring quality….we have expanded focus to quality of argument and document usability
• We are learning how to be innovative and not let the process control us

Originally published on our Knowledge Management blog

Designing the architecture of the argument in development reports

Kirk Livingston, a teacher and a medical writer working largely in the medical device industry, as well as a fellow blogger at LivingstonContent, shared this comment on my previous post regarding poor rhetorical shaping of arguments in research reports.

There’s a lot of work involved with producing solid, well-reasoned conclusions. Can it even be accomplished as an “authoring team” or is it the work of an individual? Recent research about medical device companies in Minnesota suggests communication teams are chronically understaffed. So–who has time to come to the right conclusions? Thanks for the thoughtful post.

I agree there is considerable work that goes into producing solid, well-reasoned conclusions. I am certain the work can indeed be accomplished by an authoring team. The caveat here is, it can be accomplished as long as the team engages in truly collaborative authorship work practices and makes use of pre-writing planning tools to help shape the argument.

I am not so sure that writing teams are chronically understaffed. I think the real issue here is the limits of interest and skill that team members may have towards the task of writing. As I reflect on 17 years of work associated with the authorship of regulatory documentation, I am convinced adding numbers to the equation will have little bearing on the rhetorical qualities of any given document. Larger writing teams will likely yield only emotional comfort--the notion of safety in numbers.

Producing high quality documents is a function of knowing what you want the document to do for you, a sense of where arguments must be played out in a document, and what writing tools to use in order to get true collaboration and sharpen everyone's focus to achieve the objectives you want to document to support.

Producing high quality documents in the forum of pharmaceutical and medical device research requires understanding how to build out the red thread of logic in a research report. In pre-writing planning it starts with something as simple as building a table that is to be filled in by the authoring team. The table has three columns to be completed by the team:

Primary & Secondary Objectives | Conclusions | Key Data

You then have one row in the table for each objective.

The team's task is then is to build out conclusions about achievement of each objective and what data warrants that conclusion.  A simple but powerful writing tool that helps a team to lend considerable shape to the architecture of the argument that must be represented within a report.


Originally published on our Knowledge Management blog

Effective argumentation often missing from clinical research reports

Much of clinical research reporting associated with regulatory submission strategies must be persuasive writing. In particular, discussions about the significance of study findings and how these findings directly support development claims. To win the point of persuasion, such writing must follow conventions of well-framed arguments that avoid rhetorical flaws.

I've been doing quite a bit of work over the past two months with groups who are responsible for producing clinical research reports. Reflecting back on my work, I find that many involved in authoring or reviewing these documents do not recognize the elements that contribute to effective arguments. They often confuse summaries of study findings as being meaningful conclusions about the significance of research findings.

One of the common rhetorical flaws is that authoring teams are comfortable making broad generalizations and see such generalizations as being solid conclusions and part of well-framed arguments. Broad generalizations seldom stand scrutiny of regulatory review and the generalizations of truly difficult and controversial topics never withstand close scrutiny. Faulty generalizations are easy to spot. For instance terms like......"generally well tolerated;" "suggests relevant differences;" and "may be associated with" appear throughout discussion and conclusion sections of many clinical research reports.

Originally published on our Knowledge Managment blog

4 Books Every Technical/Scientific Writer Should Considering Reading

The following books are ones that "new" technical and scientific communicators should consider reading. The books look at technical writing from different perspectives and will prove useful to the experienced communicator as well.

Metaphor and Knowledge: The Challenges of Writing Science. Ken Baake

Summary: “Metaphor and Knowledge offers a sweeping history of rhetoric and metaphor in science, delving into questions about how language constitutes knowledge. Weaving together insights from a group of scientists at the Santa Fe Institute as they shape the new interdisciplinary field of complexity science, Ken Baake shows the difficulty of writing science when word meanings are unsettled, and he analyzes the power of metaphor in science.” (partial text available from Google Books)

What Writing Does and How It Does It: An Introduction to Analyzing Texts and Textual Practices. Charles Bazerman, Paul Prior, editors

Summary: “In What Writing Does and How It Does It, editors Charles Bazerman and Paul Prior offer a sophisticated introduction to methods for understanding, studying, and analyzing texts and writing practices. This volume addresses a variety of approaches to analyzing texts, and considers the processes of writing, exploring textual practices and their contexts, and examining what texts do and how texts mean rather than what they mean. Included are traditional modes of analysis (rhetorical, literary, linguistic), as well as newer modes, such as text and talk, genre and activity analysis, and intertextual analysis.” (full text)

Technical Writing: Process and Product. Sharon Gerson and Steven Gerson

Summary: “Technical Writing: Process and Product guides readers through the entire writing process—prewriting, writing, and rewriting—developing an easy-to-use, step-by-step technique for writing the types of documents they will encounter on the job. The authors' reader-friendly style engages readers in the writing process and encourages hands-on application. Discusses prewriting, writing, and rewriting in relation to ethics, audience identification, electronic communication, and the role of technical writing in the workplace. For anyone looking to utilize more effective written communication in their jobs.” (summary and e-learning resources available at publisher's website)

Professional and Technical Writing Strategies: Communicating in Technology and Science. Judith VanAlstyne and Merrill D. Tritt

Summary: “Comprehensive and easy-to-read, this award-winning reference for those in technical, engineering, and scientific fields emphasizes practical writing. Its presentation and applications offer simple guides that users can easily emulate. It combines instruction, sample papers, exercises and writing projects for manuals, correspondence, research and publication articles, and oral technical communications.” (summary)

Originally published on our Knowledge Management blog

Why documentation work practices in pharma and medical device industries need enhancement

I recently taught a workshop for a client where I gave the participants a good news/bad news scenario. The good news, I suggested, is the documentation work practices I observed in their company were like what I saw in other pharma companies. I then suggested the bad news is their work practices were like what I saw in other companies. My point to them is that the bar for sophisticated work practices is set pretty low in the pharmaceutical industry.  I used as my line of reasoning our McCulley/Cuppan modification of JoAnn Hackos’ Document Capability Maturity Model (DCMM) she presents in her book: “Managing Your Documentation Projects.”

To this group I suggested their documentation work practices would come out at about a 2 on our 6 point scale, which suggests also the point on the scale I will place most of the documentation groups in the pharma industry. Most were surprised at the low ranking and a few were even offended I think. By the end of our workshop, all were feeling different about what it takes to create high quality technical documentation in the life sciences.

I’ll characterize here a documentation project undertaken by this group I had in the workshop and suggest such work is emblematic as to why I give them (and the industry) a low DCMM score.
The group generated a briefing document to be submitted to a regulatory health agency in advance of a request (a standard practice across the industry.) The briefing document is intended to inform the health agency as to what topics the company wanted to receive feedback from the health agency regarding an ongoing drug development project.
The company had an hour meeting with the agency and ended up wanting to address 8 topics within the hour (an ambitious agenda.)

The documentation team went through a three draft process to create the briefing package where the number of questions and the actual questions changed w/ each draft. I mean they were truly using a “fire; aim; now we are ready” approach to create this briefing package. The approach of: "activity is everything, so we are way too busy to plan."

Each draft looked dramatically different than the previous version and required massive investment of time and energy from the team. In the end the briefing package was 83 pages—that is a little over 10 pages per question. The first question did not appear until page 25 (which means there were 24 pages of introductions and throat clearing before we get to the meat. Curiously to me, none of the questions appeared in the Table of Contents of the briefing package and the document did not have an Executive Summary (we want you to work as hard in reading this document as we did in crafting it.)

Then I asked the authoring team what they did as a documentation project post-mortem for lessons learned, such as solicit usability feedback from the customer using the document or to identify how the documentation work practices impacted the process and the product. The answer was, “Oh we did not do anything like what you suggested. The document must have worked because we had our meeting with the agency. We just moved on to the next document.” I asked if they got what they wanted out of the meeting. The answer was a categorical no. “We did not get an answer to our most important question as we had placed it as 8 of 8 in the queue. We ran out of time to address that question.”

I asked how uniform their documentation practices are for the creation for briefing packages (they will generate such packages numerous times in a given year for various development projects). Response was “We have no set approach, so each briefing package will be generated utilizing variable methods and processes.”

How they could be surprised with a low rating for the sophistication of their documentation practices is the interesting question for me. Where comes the comfort with such outcomes? In part, I think, it is due to erroneously assigning the sophistication in conduct and analysis of science as carrying over to documentation work practices.

Originally published on our Knowledge Management blog

Critical Thinking Skills

I am doing some work on how to use visual thinking in the collaborative work environment and got into an interesting discussion with the client regarding critical thinking skills,  the subtle differences for application of these skills in the business place of drug and device development versus the academic place, and how well prepared people may be for the demands of problem-solving in the workplace.

As a result of the conversation, I got looking for some reference materials regarding critical thinking and methods to improve these skills.  I came across this blog by Tim van Gelder: "Bringing Visual Clarity to Complex Issues" and his post regarding how critical thinking skills are acquired. Check it out.........a very interesting read. I am quite interested in van Gelder's comments regarding "situated cognition" where he states:

CT [critical thinking] is deeply tied to particular domains and can only be acquired through properly “situated” activity in each domain.  Extreme versions deny outright that there are any generic CT skills (e.g. McPeck).  Moderate versions claim, more plausibly, that increasingly general skills are acquired through engaging in domain-specific CT activities.

Originally published on our Knowledge Management blog

The importance of understanding the reader and the need to be informed by reading theory

In thinking about the ExLPharma conference where I spoke two weeks ago on review, I talked for some time about the importance of reviewers understanding their readers and the need to be informed by reading theory so as to become a truly good reviewer. My comments were largely well received by the group attending the conference and, for most of the points I raised regarding reading theory, were truly novel for them. I came away from the conference with the notion that few people actively engaged in creating business documents have invested time in thinking about what regulatory readers actually “do” with their documents and how they actually read these mission-critical documents.

Given that most people inspect a document for accuracy tells me that the prevalent view regarding reading is “if we get the numbers and the words right, then we are good to go and surely everyone will understand what we mean.”

I remain perplexed as to why this view is so uniformly applied. I am even more perplexed why some people I cross paths with in my client settings struggle to accept the notion that readers construct a meaning that they personally create from a text, so that "what a text means" can differ from reader to reader. Readers construct meaning based not only on the visual cues in the text (the words and format of the page itself) but also based on the knowledge readers already have stored in their memory. This pre-existing knowledge readers bring with them as they encounter a text is very potent and not much appreciated by many I work with across the life sciences.


Originally published on our Knowledge Management blog