Firms write Case Studies to get free advertising. Period. Firms seek to get case studies published because a well-written Case Study will increase awareness of their product, make a favorable impression on prospective buyers, and hopefully, increase sales.

Unless you can actually get it published in a trade magazine and read by prospective customers for your product or service, there's zero point in investing the time and effort to write a Case Study.

The first thing is to understand what magazines are looking to print. They're looking for articles that will inform, educate, or otherwise interest their readers. What the trades are NOT looking for is blatant advertising, something telling the world how great your product is, highlighting its features, listing its benefits, full of glowing customer quotes, etc. If that's what you want published, consider purchasing an advertorial rather than trying to convince some overworked editor what you're submitting is actually a Case Study.

Case Studies follow a problem, alternatives, solution-adopted, lessons-learned format. In a true engineering case study, the solution adopted may or may not work. At least in theory, with a Case Study you are offering to educate fellow engineers as to what technologies may or may not work to solve a particular problem, rather than pitching them on a particular product to help solve their problem. .

In the real world, a Case Study will make enough mention of competing products and technologies, and problems faced/overcome to get it past editors, while still hi-lighting the success that can be achieved with your firm's products/solutions. It's a fine line, and how far you can push it depends on how good a relationship you or members of your PR firm has with the editors of a particular magazine.

It's tempting, when someone hands you the microphone, so-to-speak, to try and convince everyone of your product's superiority. It's not necessary. If a prospect has a problem or need that might be solved by your firm's products, chances are a Case Study, even if it's completely neutral will lead them to your website or cause them to place a call to your sales team to arrange a demo, or for product literature. Your website can contain Success Stories, glowing testimonials, feature/benefit lists, and everything else needed to excite them about your product.

Some magazines offer well-defined guidelines for Case Study submissions. At the bottom of this article are sample guidelines for Microsoft Certified Professional magazine.

Perhaps the biggest mistake firms make is procedural. Firms with little or no PR experience will simply write a Case Study, then try to get it published. The magazine world simply doesn't work that way. You'll have a better chance of publication if you approach an editor with an idea for a Case Study, perhaps a rough outline, discuss it, agree on any particular angle the editor would like the writer to take on the piece, and then go off and write the case study. Usually with only a minor revision or two this will get you in print. Sometimes they may choose to interview the customer and rewrite the article themselves. Either way, you win.

Yes, this article was helpful.

MCP Magazine Guidelines for Case Studies

A case study is an opportunity to tell readers about a project in enough detail that they can learn concrete information to apply to their own projects. Case studies should highlight both the successes and failures encountered: Did the project take longer than planned? Did several pieces of software fail to work together? Was a wrong choice made in terms of some of the pieces? What would you do differently next time? What would you do the same?

A case study is not a chance for a consulting firm to advertise its services, nor for a product to be described in glowing terms--both sides of the story need to be told.

Case Study Format

Obviously, all of the following points won't apply to every case study, and certainly not to short "from the trenches" pieces. But use the following outline to remind you of the details about the case study that you may want to include. Remember, you're charting a path for others who will be attempting a similar feat with similar resources after reading your piece. (Bold lines indicate the most crucial information to include.)

The first paragraph of the story should not only draw the reader in, but should give a quick summary of what the "hooks" of the article will be: "When Pacific Bell decided to migrate its Microsoft Mail system to Exchange, the IT department had no idea that the biggest challenge would be …"

I. What the system consisted of before

· Description of what it did

· Hardware and software

· Personnel involved with supporting it

II. Business problems

· Why change the system?

· Did management, MIS, or users need convincing? (Advice?)

III. Approaches considered

· Why discarded or accepted

IV. Personnel brought in to handle the job

· Why they were chosen (third-party party vs. in-house vs. new staff)

V. Systems to be created

· Goals

VI. Cost factor

· Current expenses

· Anticipated savings or expenditures

VII. Time Table

· How job was broken down

· Estimated time required for each phase

VIII. Software

· Software (server, app dev tools, backup system, audit, disaster recovery, tools)

IX. Hardware

· Network, PCs, backup, other

X. Configuration

· Physical location of equipment

XI. Development

· Prototyping

· Actual coding, or implementation

XII. Making the cutover

· Testing, QA, debugging

· Problems that surfaced

· Tricks uncovered

XIII. Business as usual

· Who handles support

· Who's responsible for updating, problems, etc.

XIV. Reassess and review

· Do's and don'ts for readers

· Surprises

· Unplanned benefits

X. Things you wish you'd done differently