This may sound like a rhetorical question, but I have worked with many people in the pharmaceutical industry for whom readability is not high on the list of priorities. For documents to be submitted to regulatory agencies, the accuracy of data and compliance with regulations are certainly the most critical concern. After this, however, importance can vary widely among members of a drug development team on specific issues, ranging from strict adherence to in-house templates and styles to how many tables should be replaced by figures. More often than not, team members just want each document to look exactly like every other document of the same kind written within the company for the last 10 years. Those got the drugs approved, didn't they? If the process isn't broken, why fix it? 

It is understandable that readability is not a major concern. Regulatory writing is generally considered the most rigid and standardized genre of medical writing. The industry around the world follows ICH guidelines and templates for study reports, protocols, and summaries, which can breed a sense of complacency. Regulatory agencies employ experts in the review of applications, who surely do not mind highly complex data presentation, dense text, and lots of jargon. In addition, standardization and uniformity are indeed important in technical writing (that's another subject onto itself), although they are often confused with a lack of flexibility. Most important, submissions are often put together under very tight deadlines, and there is simply no time to bother with such "luxury" as document readability. 

So why does readability matter? The answer is simple. On the other side of each submission, a real person will read these documents, and it is to your advantage to get on their good side. 

When I worked as an FDA labeling reviewer, I read many briefing packages and new drug applications and, in some cases, felt the frustration of wading through poorly written and illogically organized text. I heard medical reviewers sigh with resignation. One person said she wished that poor writing were grounds enough for refusal to file. Poorly written documents take longer to read and absorb, are less persuasive, and reduce the effectiveness of the message. 

Think about the workload of the medical reviewers who will look at your submission, and imagine how much a crystal clear, easy-to-read, logically organized application would lighten their mental load. Everyone has experienced the sensation of smooth sailing when reading a well written article with no "bump" of confusion or disconnected reasoning. The mood of the reviewer depends on the readability of your documents, which in turn may leave a general impression in your favor. Even if your data are overwhelmingly and indisputably positive, readability can substantially reduce the review duration and get your product on the market a few days before the mandatory review deadline. This can mean thousands or millions of dollars in extra revenue or an edge over your competitors. 

Nathaniel Hawthorne wrote, "Easy reading is damn hard writing." That truth applies even more to technical writing than to fiction, where data are abundant and complex.  

For a period of time I was the only medical writer in a small contract research organization (CRO), working closely with the regulatory affairs department. I learned some project management skills that, I later realized, are valuable tools for writing large, complex regulatory documents. 

Regulatory documents, such as clinical study reports, clinical summaries, and overviews, require many interconnected deliverables from numerous team members with constantly shifting timelines. Any delay in one deliverable can potentially result in a large downstream effect. The regulatory writer is a juggler who has to keep all the balls in the air in order to meet her own deadline. This is where project management tools come in handy.

One of the most used tools by project managers is the Gantt chart. It may look complex and tedious upon first glance. However, after creating a few Gantt chart myself in Microsoft Project, my entire thinking about the process of medical writing shifted.

The Gantt chart forces you to focus on the most important elements in a timeline: 1) the rate-limiting steps, 2) the key people, 3) the high-risk tasks. The rate limiting steps are the deliverables that can hold up your work if they are not provided on time. A good example is the final tables and listings or pharmacokinetic results for a study report. The key people are those without whom you can't get the document finished, including the signatories and QC checkers. The high-risk tasks are steps that are most likely disrupted or delayed. For example, if you have under-estimated the days you need to write a draft or a section, you may become the delay. If you keep your eyes on these 3 elements continually, the rest is cruising.

Even if you don't have MS Project and do not want to create and maintain your own Gantt chart, drawing a diagram of your timeline from time to time can be a useful mental exercise. It often clears your mind and simplifies a project that seems overwhelmingly complex.

Perhaps most valuable in the exercise is the psychological benefit of managing your own timeline: As a writer I get a sense of control of the documents I'm working on over a long time; at any moment I know exactly what I need, when, and from whom. If I have slipped behind a little, I can make micro-adjustments as soon as possible and never have to "cram" in the end, thus creating a smooth and pleasant experience.

When I was first given the timeline some months ago, my first thought was "It cannot be done." The company was planning to file an NDA. Two phase 3 studies were to reach database lock in June. I, the lead medical writer on one of the clinical study reports, was requested to complete the first draft of the results (Sections 10 through 13) in 4 working days and the entire document, from TFLs to sign-off, in 3 weeks. I am a fast writer. I have written several first-draft CSRs in three whole days. However, those CSRs were small --- phase 1 or phase 2, involving no more than 50 subjects. The endpoints were generally pharmacokinetics and safety, and the text portion (Sections 5 through 13) was usually 40 to 60 pages.

This time, the phase 3 study was a pivotal trial of approximately 350 patients with analyses on half a dozen efficacy endpoints and a dozen safety endpoints. The report contained 50 in-text tables, 10 figures, and over 100 post-text tables and figures (Section 14).

In the end the impossible was done: The first draft was written in 4 working days and the final version was ready for sign-off in 3 weeks, including editing and QC. (Another writer wrote the text Section 12 Safety, which shaved a day off. Without the assistance I would need 5 working days for the entire draft.) Besides the large-scale coordination and collaboration among all the departments involved, I learned a few lessons specific to writing:

1. Preparation. Do as much as possible before the clock starts ticking. Finalize the "shell" by working with the team. Work with biostatisticians and data programmers to review and understand all the tables and figures. Get the appendices lined up. Establish an internal style guide.

2. Immersion. The fastest way of writing a study report is to hold in your brain as much information about the study as possible before and during the writing. If you don't need to look up the definition and assessment method of every endpoint, you can carry on describing the data accurately and correctly without a pause and achieve the "flow" that makes the work enjoyable. 

3. Brevity. To write concisely is generally desirable but especially critical in a shortened timeline. Do not repeat every data point in the in-text tables. The text is used to draw attention to key efficacy and safety results. Focus on the data that support the endpoints.

4. Communication. If you need help, ask. Do not wait. The medical monitor and statistician are your most valuable resources to help you make sense of the data. They can help you resolve data anomalies and clarify ambiguity. Report your progress often, so that the team is aware of any risk to the deadline and can lend you a hand if necessary.