Anyone who’s ever been involved in choosing enterprise software knows it’s not an easy job. It takes months of preparation that involves gathering information from various departments, mapping business processes, preparing a business case, interviewing stakeholders, and getting buy-in from executives and users on the project. And that’s only the beginning!

But whose job is it to do all of this anyway? It’s often assumed that someone in IT (a technical professional) will be responsible for it. Other assumed targets are the Chief Executive Officer (CEO), the Chief Technical Officer (CTO), and sometimes even the Chief Financial Officer (CFO)—depending on the type of enterprise software that is required. But believe it or not, most often the person that is handed the title of software selection “Project Manager” or “Project Champion” is just an ordinary Joe—(or Jane to be politically correct)—a department manager or project coordinator who knows the organization’s business processes like the back of their hand. While he (or she) may not have any particular technical expertise, he may certainly be able to add value to the project by knowing the business. So, why not; who better to handle this type of job, than someone like that?

Which brings me to the point of my story… Read the rest of this entry »

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.

Read the rest of this entry »

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.

Read the rest of this entry »

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…!

Let’s face it; we’ve all had to deal with pushy salespeople.

How do they always get you to buy stuff—even when it’s something you didn’t need? It’s called the sales pitch. Every salesperson has one, and software vendors are no exception. In fact, they have several ways of pitching their products.

One such way is through a white paper—which often discusses particular problems that many companies may be facing. At the same time, it gives vendors the opportunity to enlighten you about the one possible solution that can “fix it.” However informative it may be, ultimately a white paper is a cleverly written sales pitch—a pitch containing certain buzzwords that gloss over the practical realities of their solution.

Here are ten of the most ambiguous buzzwords I’ve seen used in white papers—and they may make you think twice about whether or not a software vendor is truly focusing on your best interests.

Read the rest of this entry »

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.

Read the rest of this entry »