Writing White Papers

White papers are a regular output in the technical world–especially in the aerospace and defense industries. This post will cover some of the basics, such as, what exactly is a white paper, and why would you or your organization want to write one, and what’s the format?

A white paper is a short document, usually 2-10 pages, that proposes a solution to a particular problem–technical, political, social, or other. In the case of a solution to a technical issue, a company will share just enough proprietary information to provide the general outline of their solution (unless they classify it or add a bunch of proprietary notices to it). The idea with a white paper is usually to attract attention: “Hey, we’ve got this great idea, ask me for more!” And the “more” would be, for example, a formal proposal for paid work.

Below is one format for white papers I used at NASA, along with the content and length guidance. Some of the language is mine, some of it was forwarded to me.

ABC Widget for Solving Problem X

Executive Summary

This is an overall summary of your white paper. Ideally, this should be written last to make certain that you’ve covered all of the main points of your proposal—the problem being solved, summary of technical approach, benefits of your approach, and a bottom-line cost and schedule. Your paper title should be short, descriptive, and easily understood for a non-technical audience (3-4 paragraphs, no more than one page).

Introduction

This should be a short paragraph or two (2-4 sentences each) describing the problem you are attempting to solve.

Background

This section should describe why the problem you are solving important and to whom—i.e., who needs this solution and what benefit(s) they derive from it, what approaches have been used to date, and why a new approach is needed (3-5 paragraphs).

Methodology

Here is where you describe your approach to solving the problem at hand. This should include the physical/technological principles involved in your solution, what the individual components will do, and what the anticipated results/outputs would be. In addition to a description of your approach, this section should note where your solution results in innovations or improvements in the following areas:

  • Technology
  • Management
  • Integration
  • Cost
  • Schedule

If you are using this white paper as the basis for a proposal, this is a good place to do a “sanity check” on your content to make certain that you are answering the questions the solicitation is asking.

Other items you might wish to cover are:

  • Description of the team—personnel and key partners—who you are, what sorts of similar problems you’ve solved previously, and why you are ideally situated to solve the problem you intend to solve
  • Description of facilities—labs, special test equipment (STE), or other facilities your team has access to that will help you execute your solution
  • Description of costs and schedule—what your solution will cost to implement, what that money buys, and how long it will take to execute

(5-7 pages)

Conclusion

The conclusion should summarize the key advantages and the benefits of your approach (3-5 sentences).

About Bart Leahy

Freelance Technical Writer, Science Cheerleader Event & Membership Director, and an all-around nice guy. Here to help.
This entry was posted in documents, technical writing and tagged . Bookmark the permalink.

2 Responses to Writing White Papers

  1. ProsWrite says:

    I’m enjoying your blog, Bart.

    You may be interested in my series on writing white papers. A couple of years ago someone asked me for resources on writing them and, when I couldn’t find much, I started doing some research about them to develop evidence-based guidelines. My most recent post has links to the earlier ones: proswrite.com/2014/10/14/what-have-we-learned-about-content-and-its-purpose-in-white-papers/

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.