Jakob Nielsen is a name some of you may recognize. He is a self-appointed guru on all matters regarding usability of web sites and web-mediated work tools. You can find much of his work summarized on his web site titled Useit.
Last week Nielsen came out with his list of Top 10 designed business Intranets for 2011. Here's the link.
I noted with interest Nielsen's comment "If there's anything that has been overused, abused, and hyped beyond the level of cliché, it's "knowledge management." Thus, it might be better to say that many of this year's winners were strong in "managing knowledge" on their intranets."
Managing knowledge. This is a concept where I see drug and medical device teams struggle all the time. One reason for the struggle is the slow uptake of tools that can help foster an effective work environment and change deeply ingrained cultural practices.
I believe intranets, such as WIKIs are great tools that should be deployed at the project team level. These platforms become incredibly valuable from the moment a clinical development plan is written until well after a dossier is submitted to the regulatory authorities.
While it is true that knowledge management is not a technology issue, effort must still be spent in providing a suitable environment to facilitate knowledge capture and sharing.
I am suggesting the use of team specific intranets as a way to promote cultural change in an organization, at the level of knowledge-sharing activities and also for shaping broader work behaviors. In most companies where I train or consult, little has really changed since the 1960s in how people approach the planning and authoring of documents. Using intranets, like a WIKI, can quickly get a team applying best practices in terms of pre-writing planning.
The McCulley/Cuppan Blog on Tools and Strategies for Improving Quality of Knowledge Management and Communication in the Life Sciences.
Showing posts with label collaborative writing. Show all posts
Showing posts with label collaborative writing. Show all posts
12 January 2011
23 October 2010
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:
Originally published on our Knowledge Management blog
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
26 August 2009
What’s Wrong with PowerPoint as a Document Authoring Tool?
In our McCulley/Cuppan consulting work we recently had a new client invite us to work with an authoring team on applying best practice to the planning, writing, and reviewing of a regulatory submission document. The document was going to be a significant piece of work, requiring over 500 pages and involving multiple authors across several scientific disciplines.
At the first meeting, the project leader announced she wants to continue the use of PowerPoint (PPT) as the document planning tool. Reasoning for this approach was in part because she and other team members already invested considerable time and effort in generating a 540+ slide deck representing data and messages to be in the regulatory document and PPT was a very familiar tool from extensive use in developing presentations.
I have to say we were mildly surprised by the demand to use PPT as the primary tool to plan and outline such a large, complex document. We have encountered other organizations using PPT for document planning purposes, but never on such a large scale. On the surface, the choice of PPT as the tool to produce initial draft documents seems reasonable. It is familiar to many, provides an authoring environment that produces output that can appear on screen as an outline, can be commented on in oral or remote review, and can be easily augmented and updated. All of these apparent benefits would support an argument for using PPT as an outlining tool to plan any and all documents. However, the use of this tool does not readily scale to developing large, complex technical documents.
Christine Haas, Karen Schriver, Thomas Huckin, Edward Tufte, and others tell us much about how readers interact with and read texts. From this collective body of work we have learned some things that can help us produce texts in an effective manner that, equally, is perceived as of very high quality. The prime method is to use tools that enable the design and review of texts as you expect your readers to engage in the reading and analysis of the text.
Successful collaborative authoring is significantly rooted in careful and thorough front-end planning. Choices of authoring tools are among the critical aspects of the document planning process, as tool choices impact (enabling or constraining) every other aspect of the planning and documentation processes. As authors and managers of authors, it is incumbent upon all of us to choose tools that accommodate our desired set of outcomes. Authors and managers must be cognizant of authoring tools that accommodate not only themselves and their ways of working, but others as well.
It is our position that use of PPT for document planning negatively impacts all potential collaborative authoring and review outcomes. Our claim assumes that the goal of the work is to generate an effective document, economically produced, that meets or exceeds end-user expectations.
I have outlined here key advantages and disadvantages of using PPT to plan and facilitate documentation of a multi-year, complex pharmaceutical development work.
PPT Advantages
Originally published on our Knowledge Management blog
At the first meeting, the project leader announced she wants to continue the use of PowerPoint (PPT) as the document planning tool. Reasoning for this approach was in part because she and other team members already invested considerable time and effort in generating a 540+ slide deck representing data and messages to be in the regulatory document and PPT was a very familiar tool from extensive use in developing presentations.
I have to say we were mildly surprised by the demand to use PPT as the primary tool to plan and outline such a large, complex document. We have encountered other organizations using PPT for document planning purposes, but never on such a large scale. On the surface, the choice of PPT as the tool to produce initial draft documents seems reasonable. It is familiar to many, provides an authoring environment that produces output that can appear on screen as an outline, can be commented on in oral or remote review, and can be easily augmented and updated. All of these apparent benefits would support an argument for using PPT as an outlining tool to plan any and all documents. However, the use of this tool does not readily scale to developing large, complex technical documents.
Christine Haas, Karen Schriver, Thomas Huckin, Edward Tufte, and others tell us much about how readers interact with and read texts. From this collective body of work we have learned some things that can help us produce texts in an effective manner that, equally, is perceived as of very high quality. The prime method is to use tools that enable the design and review of texts as you expect your readers to engage in the reading and analysis of the text.
Successful collaborative authoring is significantly rooted in careful and thorough front-end planning. Choices of authoring tools are among the critical aspects of the document planning process, as tool choices impact (enabling or constraining) every other aspect of the planning and documentation processes. As authors and managers of authors, it is incumbent upon all of us to choose tools that accommodate our desired set of outcomes. Authors and managers must be cognizant of authoring tools that accommodate not only themselves and their ways of working, but others as well.
It is our position that use of PPT for document planning negatively impacts all potential collaborative authoring and review outcomes. Our claim assumes that the goal of the work is to generate an effective document, economically produced, that meets or exceeds end-user expectations.
I have outlined here key advantages and disadvantages of using PPT to plan and facilitate documentation of a multi-year, complex pharmaceutical development work.
PPT Advantages
- use is a habituated format; it’s familiar.
- presentations constrain data reporting rather than facilitate collaborative/interpretive processes (see my previous blog post on PowerPoint presentations).
- format creates/maintains a huge but fragmented vision of the process and product, impacting output (see Schriver and Tufte).
- PPT does not scale well to large documents as it limits information organization and searching is cumbersome, impacting review and the authors' ability to migrate material from PPT into a document-based format.
- PPT presentations do not accommodate major revisions/reorganization; impacting logic, content, and organization of the ultimate document product (see Schriver).
- the output decreases in clarity as the number of slides increases, impacting author/reviewer interpretation (see Tufte).
- PPT output is not a document; conversion to MS Word format is inefficient, time-consuming, and expensive.
Originally published on our Knowledge Management blog
20 April 2009
Improving the Practice of Document Review
Document reviews should be used as a tool to build quality into research and technical reports. In most handbooks for professional writers, review is recommended for clear and simple reasons: it is intended to identify problems and suggest improvements that enable an organization to produce documents that accomplish its goals and meet readers’ needs. It is true that science creates devices and drugs, but it is the documents that secure product approval and registration from the FDA and other regulatory agencies.
To create high quality documents in the most efficient manner, reviews must take place at various stages of document development. No matter the stage, all reviews should be strategic—that is they need to address the fundamental question of whether the document makes the right argument about the data described in the report. Reviewers should ask if the document stands up to challenge and fully justifies its conclusions. They should ask whether the reader is given enough context to understand the positions expressed in the document.
Review allows subject matter experts and upper management to add information that may not be available to authors. Review offers an opportunity for building consensus across functions within an organization.
Review is a process of evaluation that focuses on the functional elements of a document (what the document is supposed to ‘do’ or supposed to ‘say’). We can characterize the major purposes of review in descending order of importance as follows:
Originally published on our Knowledge Management blog
To create high quality documents in the most efficient manner, reviews must take place at various stages of document development. No matter the stage, all reviews should be strategic—that is they need to address the fundamental question of whether the document makes the right argument about the data described in the report. Reviewers should ask if the document stands up to challenge and fully justifies its conclusions. They should ask whether the reader is given enough context to understand the positions expressed in the document.
Review allows subject matter experts and upper management to add information that may not be available to authors. Review offers an opportunity for building consensus across functions within an organization.
Review is a process of evaluation that focuses on the functional elements of a document (what the document is supposed to ‘do’ or supposed to ‘say’). We can characterize the major purposes of review in descending order of importance as follows:
- Attending to purpose in terms of confirming content matches purpose of the document; logic of the arguments are complete and relevant, and the organization of the document content will readily support what the reader wants to do with the document.
- Attending to audience in terms of confirming precision of the discussion (semantics); sufficient contextual information; and ease of navigation.
- Attending to compliance in terms of confirming accuracy and completeness of content; consistency of style; and reasonably well-structured grammar.
- Involvement of critical stakeholders early, defining their roles and responsibilities.
- Articulation of the targeted scope, purpose(s), and message(s) for the final document.
- Shared quality standards for the final document product and formally described procedural agendas for the who, what, when, and why of review.
- Identify and plan phases of review and associated priorities.
Originally published on our Knowledge Management blog
Subscribe to:
Comments (Atom)