Friday, March 5, 2010

A Template for Creating Outlines for White Papers on Technical Subjects

A Template for Creating Outlines for White Papers on Technical Subjects

By Jerry Fireman

Structured Information

Arlington, MA

 

What’s most important in developing white papers on technical subjects is what you say rather than how you say it. The outline is where you determine what you are going to say in the document. The most successful white papers follow a tried-and-true problem-solution format. This document will provide a template for developing an outline for a problem-solution format white paper along with an example.

1. Introduction

The introduction should be a brief summary of the entire paper, hitting briefly on each of the main headings below. Ideally, the length should be only one paragraph to give the reader a quick summary of what they are going to gain by reading the full document. The focus of the introduction should be on a generic statement of the problem and the solution addressed in the white paper, preferably without introducing any company specific-solutions. The last part of the introduction should hit on the benefits provided by the solution.

 

Example:

The introduction does not normally need to be outlined

 

2. Trends

 

The trends section of the outline should be an overview of how trends are causing and exacerbating the problem that will be addressed in the white paper. The focus is normally on technological changes and economic trends but trends in the marketplace can also be covered. This is a good place to bring in third party references such as from industry experts or research organizations.

 

Example: Aerospace industry facing challenges

Complexity increasing

Long project lifecycles

Potential for many more projects

Budgets squeezed

Talent crisis

Need to coordinate virtual enterprises

 

3. Problem

Here’s where we define the specific customer problem that we are addressing. This is arguably the most important section of the white paper because if the reader doesn’t buy into the problem then it is unlikely that he or she will consider buying the solution. It’s important that this section addresses a real problem faced by potential customers in their own language as opposed to marketing hype. It’s good to bring in metrics or quotes by actual users to provide validation.

 

Example: Conventional program management methods not up to the challenge

Projects over budget

Data is highly dispersed and fragmented

Old way of working – multiple tools for specialists, program status consolidated manually and reported in Excel and PowerPoint – stand-up meetings

Resulting business problems

 

4. Solution

 

This section explains exactly how your solution works and how it differs from alternatives. It’s best to maintain objectivity at this point by being descriptive rather than selling. The solution section talks about features rather than benefits to give your potential customer an understanding of what it is you are offering.

 

Example: New generation of program management systems can meet the challenge

New way of working – everyone goes to one system

Multiple specialist tools integrated to provide consistency

Stand-up meetings with program management system

Single version of the truth in real time

Single repository for project information

Ensures entire organization knows what requirements need to be met

Aligns, synchronizes and shares contracts and subcontracts

Ensures all promised data deliveries occur on time

Formally define format in which data is to be provided by extended enterprise

Ensure all players know and communicate their intended product architecture

Communicate items requiring special care and attention

Disseminate responsibility selections to extended partner team

Synchronize sub-contract activity with configuration and deliverables management

Define and manage product end-item builds

Execute and manage risk reduction strategies and report risk status

Easily access a consolidated list of assigned issues across all projects for execution and closure

Data accessible from Microsoft desktop tools

Collaborate on review and audits

Providing traceability of information

Evolving the product definition

 

5. Benefits

Now that we have established our credibility by defining a problem and a solution we can start talking benefits. Making a major purchase usually requires demonstrating return on investment (ROI) so this section should focus on making the case that the solution provides a return far above its cost. Wherever possible provide metrics that will help potential customers begin to calculate quantitative advantages such as higher revenues or lower costs.

Example: Results

Keys to better program outcomes

All program members know what requirements they are supposed to meet

Suppliers and partners report their status in real time

Rollup status across programs and divisions

Use limited skilled resources effectively

Leveraging supplier’s IP while protecting it properly

Embed knowledge into the tools

Measure performance in real time across a consistent and common set of metrics

Maintain IP security automatically

 

6. Examples

 

The next step is to prove the benefits of your solution by providing real-world examples. If your solution is on the market and you have people successfully using it, this section can consist of several short case studies. Mentioning the actual customer names is better but not essential if you are having difficulty getting permission to use their names. If you don’t have customers for your solution yet, then provide hypothetical examples of how potential customers in a particular situation could benefit from using your product. Whenever possible, provide numbers that demonstrate the return on investment delivered by your solution.

 

Example: Case histories

Company A

Company B

Company C

Company D

 

7. Conclusion

The conclusion should summarize and reinforce the entire white paper with an emphasis on the benefits provided by the solution. Finally, the solution should conclude with a call to action.

 

Example:

The conclusion does not normally need to be outlined

 

About Structured Information

 

Jerry Fireman has written over 5,000 white papers on a wide range of technology subjects for companies such as Microsoft, Oracle, Cisco, Honeywell, Emerson, and many others. His company Structured Information specializes in writing and illustrating technical content that meets the requirements of leading companies and publications around the world and placing the content in publications and social media. Structured Information produces marketing materials that communicate effectively with your prospects and customers in their own language while requiring minimal effort on the part of your technical and marketing staff. Structured Information's project focus lets you try its services one project at a time.

 

Examples of typical white papers written by Jerry Fireman (many more can be found at http://www.strucinfo.com)

 

http://www.designworldonline.com/articles/4925/21/Integrate-Model-based-Machine-Design-with-Motion-Control.aspx

 

http://www.nxtbook.com/nxtbooks/mediasolutions/windsystems201001/#/52

 

http://medicaldesign.com/contract-manufacturing/manufacturing-production/servo-motors-digital-filters-20091201/index.html

 

http://health-care-it.advanceweb.com/editorial/content/editorial.aspx?cc=213238

 

If you like this document, Jerry would really appreciate it if you would blog about it or provide a link to it: http://www.strucinfo.com/wwwstrucinfocom/2010/2/10/a-template-for-creating-outlines-for-white-papers-on-technic.html

 

 

Contact information:

Jerry Fireman

Structured Information

Phone: 781-674-2300

Email: jerry_fireman@strucinfo.com

Website: http://www.strucinfo.com

 



---------------
Lynn M. Miller, LMA, LLC
Business Development & Consultation
*The Professional with a Flair!*
Phone: 718.506.2329
Fax: 718.228.7331
lmallc@vmdirect.com
www.lmallc.com


Posted via email from LMALLC By SocialNetGate

No comments:

Post a Comment