One of the biggest challenges (or business pain points) for pharmaceutical manufacturers (or life sciences companies) is the long cycles that are required for research and development (R&D) and product approval. This is particularly a challenge for manufacturers of generic drugs, for which cycle times can average 20 months or more (and the full time-to-market period upwards of 12 years).
Why are long cycles a problem?
E-mail, Internet access, and collaborative tools (whether a phone system’s conferencing capabilities, or document-sharing applications) are “must-haves” for most businesses today.
But by now many managers know that you shouldn’t stop at just implementing these tools and then going ahead, footloose and fancy-free, with using them. As with any other asset, you need to protect not just the technology that enables these tools and applications, but also the information that these tools allow users to share.
To ensure the confidentiality of private information—and help ensure compliance with regulations and internal policies—information security software is now also a “must have.”
Not so long ago (or, back in the early ’90s, when I was a first-year college student) there were two ways to get a post-secondary education: by attending classes at a university or college with hundreds of other coffee-stoked students, or by signing up for what used to be called “distance” learning (or even before that, “by correspondence,” as though courses consisted of a series of letters exchanged between the student and the professor, and delivered by the Pony Express). Distance courses still exist, of course, but increasingly, even these programs are undergoing drastic change because of their use of technology.
Over the past decade or more, a new style of education has been emerging for traditional in-class college and university programs as well, changing the ways instructors and professors teach and students learn. Humanism—the philosophy originally espoused by universities—has always held that technology could and should be used, along with rationality, ethical philosophy, and universal morality, towards improving the human condition. However, it seems that the balance is being tipped increasingly towards a privileging of technology over other means to that end.
Come on, admit it: you read your horoscope. Maybe not every morning. But you do read it, even if just for comic relief, or because it allows you to feel a surge of superiority before you head out the door to scrape your car or pummel your way onto public transport. Either way, reading your horoscope is a pleasant diversion.
But here’s a horoscope for the new year that provides you with more than just coffee-side chuckles. If you read between the lines, you’ll find useful tips about the software selection process, and links to valuable software evaluation resources.
Aries: Don’t just start that software selection process— finish it. But you’ve got to realize that sending out request for proposal (RFP) templates to the vendors on your shortlist, and creating a scripted demo may be more than you can handle alone, no matter how independent you are. Exercise your brilliant leadership skills: delegate to your nearest and dearest Libra.
Here’s the final point in a series of four aimed at identifying a “good” IT white paper (and providing helpful hints, should you need to write one). The previous points addressed the importance of the white paper’s introduction, of writing to a specific audience, and of proposing a viable solution. The final point, appropriately enough, considers key features of an effective conclusion.
4. All’s Well that Ends Well…
The first paragraph of the white paper is important, but no less so the conclusion. It should be “practical and memorable,” according to both Michael Stelzner and Ed Gandia, a technology copywriter. And for best effect, it should include a call to action: a clear (doesn’t hurt to say it again) statement that compels the reader to do grab that bull by the horns and make a decision.
Here is the third point in a series that looks at the key features to consider when writing an IT white paper… so that you not only get your reader’s interest, but keep it.
Are you part of the problem or part of the solution?
Identifying a problem isn’t enough, no matter how much “affinity” is established with the reader (see previous post and Michael Stelzner’s site). The proposed solution must be both practical and clearly stated.
And here’s the second point that all writers of IT white papers should keep in mind when writing (special notice of this point should be taken by those writers who may *forget* that not everyone on the planet has the same rarified vocabulary, not mentioning the names of any jobs or fields…).
2. Audience, Audience (Stake a claim with your first paragraph).
After the compelling title, the first paragraph makes or breaks audience “affinity,” which is Stelzner’s term for the white paper’s ability to identify a problem or a situation with which the reader can identify. Focusing on the reader’s needs, and highlighting the “pain points”—the bugbears the reader hasn’t yet had any luck dealing with—makes a white paper more credible than one that only brags about the genius behind the featured product or service.
And, it should be clear in the first paragraph the nature of that audience: Is it composed of engineers? CFOs? Retailers, or suppliers? Each of them, according to Stelzner, has a different perspective on the same problem, and has different needs that must be satisfied by different solutions. In any case, aim to use language that could be understood by almost anyone in any field or industry, even if your content is targeting a particular field or industry. But no matter how savvy your audience, a string of jargon is not going to sell your idea or product as effectively as plain language that is used cleverly or creatively.
Want more tips? Check out SherryFox’s smart post about “Ambiguous White Paper Buzzwords” for more on what language NOT to use when you’re writing a white paper…
and keep checking for points three and four, coming soon…!
A white paper is a document or “brief” (and yes, perhaps unfortunately, I mean “brief” in the sense of something that informs rather than something that is short—white papers are sometimes as concise as newspaper editorials, or run as long as the latest “… For Dummies” book; examples of this will be provided in upcoming posts). A white paper’s purpose is to educate the reader, who is the potential customer/consumer of a particular industry’s service or product. The author of the white paper aims not just to inform readers, but also to persuade them to clamor after said service or product. Or, at the very least, readers are encouraged to consider the product’s use and benefits—information which may help in making key business decisions.
White papers are intended to inform—and to sell an idea or a product. Another way to look at it: a white paper identifies a need (or more cynically, creates a need or desire) and then suggests a solution. After all, as Michael Stelzner, a recognized expert in white paper writing, says: white papers are “powerful marketing tools” (or, in a more hyperbolic moment on his blog, “atomic marketing weapons”). In spite of this underlying purpose, it is generally understood that a white paper—or at least a good one—shouldn’t be overtly “salesy.” Or, in other words, a white paper is not supposed to be an infomercial in silent portable document format.