Hogwarts: An enterprise IT case study
The challenge
Educational institution suffered from poorly documented legacy systems; decaying physical plant; unpredictability in student classification; difficulty detecting and preventing external threats.
The solution
Partnered with PhoenixOrder, leveraging our unique capabilities for process improvement and problem resolution. “Only Phoenix could help us drive optimized outcomes against our CEO’s remarkable vision,” said Hogwarts’ director of IT, Argus Filch
The results
• Retained and re-skilled majority of existing student body
• Matriculated second-generation class in highly desired Millennial demographic
• Achieved 80 percent masonry replacement
Ah, the case study, that shop-worn staple of enterprise IT marketing. Like our made-up Hogwarts case, most of them stink.
An IT vendor client recently asked us to rethink case studies. It wanted a fresh approach to the content and presentation. Our response: “Huzzah!”
We locked a writer and a designer in the basement for two weeks (well, the door wasn’t locked) and told them to first analyze and deconstruct case studies, and then rebuild them based on what they’d learned.
Here’s what we found and what we recommend doing.
Why do people read case studies in the first place?
Collectively, we’ve interviewed and written for the enterprise IT audience for more decades than we’d like to admit. Over the years, we’ve observed two types of audiences among case study consumers.
Some readers just want to see the results at a glance. For them, the case study doesn’t function as much more than a testimonial quote with a little supporting data. These readers may be looking for “decision support,” but only at a high level. Let’s call them Scanners.
Other readers are deeply considering a project or idea similar to the one the case study highlights. They want details, they want to compare and contrast their own IT and business environment, and they want very granular decision support. Let’s call them Researchers.
So our first foundational thought was that a great case study has to deliver value to both of these audiences.
What else would make a case study great?
Have you ever worked with a team to solve a complex business problem? Did you solve the problem by just pointing a magic wand and saying, “winguardium leviosa”?
Of course not. Yet many case studies give that impression.
Like the Harry Potter books (and NOT like our formulaic rewrite above), real-world IT projects are full of mystery, imagination, and dramatic tension. (Really!)
So why do so many case studies lack the captivating details Researchers seek? Why do they fail to deliver decision support Scanners need? And why, moreover, do they suck? We knew that we couldn’t propose a better approach before we understood why things are going wrong. So we dug in.
The problems point to the processes.
Sometimes, people producing the case study fail to capture it the kind of detail Researchers are looking for simply because they don’t understand the material.
Sometimes, it’s because one person conducts an interview, and a different person writes a case study based on it. Details and color get lost in the hand-off.
Sometimes, it’s because people producing the case study’s rich-media assets—video, audio, infographics, animations—aren’t coordinating well with the writers.
Sometimes, it’s because the writers are using so-called marketing language rather than normal human language. (If you go to a cocktail party outside of Silicon Valley and talk about leveraging synergistic solutions for optimized outcomes, you will quickly wind up standing by yourself.)
Sometimes, it’s because drafts circulate through many review cycles among several parties, and each revision chips away at reader value. (For a painful illustration, see “How to ruin your B2B content marketing, one revision at a time.”)
And sometimes, it’s simply because people think they need to remove all traces of the conflict, uncertainty, or misstepping that every complex project encounters in order to look good.
Even when you have smart and well-intentioned people working on a case study, these process problems can lead to a cookie-cutter story lacking interesting color and detail. It therefore lacks value to Scanners and Researchers.
To find good examples, we broadened our thinking.
Our search for examples of case studies that actually do appeal to Scanners and Researchers led to another insight: Our framing of the task was too narrow.
What we really wanted to find, it turned out, were detailed, reader-oriented case studies about business and technology. They exist. They just aren’t necessarily produced by IT vendors like our client.
First, take a look at the case studies at the heart of Harvard Business School’s curriculum. Unlike our client, HBS doesn’t necessarily have a business goals related to the subjects of its case studies. But like our client, it aims to grab and hold the reader’s attention, and make him want to connect and learn more.
Another place to look for good examples is in the IT media.
Over the years, CIO.com and CSOonline.com, where I worked for many years, have produced some very detailed case studies. The fact that they weren’t written with a product sales agenda helped make them credible and valuable. Take a look at this profile of Western Union’s business transformation and this one on a video surveillance system. Going further back, Baseline magazine set the bar even higher, often creating tools such as spreadsheets and ROI calculators to accompany case studies.
We found plenty of proof that profiles of enterprise IT projects don’t have to be boring, superficial, and formulaic.
So how do you create a compelling case study?
Through our analysis, we determined that bad case studies have many different causes.
There is thus no one “magic wand” way to produce good ones. But there are a few things to try:
- Improvement starts with the agreement that it’s needed and possible! Gather a working group. Socialize (i.e. look at, forward, and discuss) examples of more engaging content.
- Create a more coordinated internal process for producing case studies. Consider all asset requirements and possibilities up front. This will make production more efficient.
- Take a journalistic approach to reporting a case study project. (Yep, that’s our bias, but it works!) If the goal of reader service is paramount, then it follows that you can’t be afraid to reveal pain points, including moments of uncertainty and conflict. Those details will provide invaluable decision support for readers. They will also help the reader engage with the story, as well as develop empathy for and trust of its subject.
- Plan for A/B testing. Test your presentation formats. Test journalism-style case studies versus more traditional marketing collateral. Test headline styles. Just be sure to define your testing goals realistically. We believe that deeper engagement with case studies will ultimately lead to better business performance.
In this particular client engagement, we proposed an expand/collapse presentation mechanism. This would allow Scanners to see their desired level of information at a glance, without dragging them through a long project profile, while allowing Researchers to dive into whichever aspects of the work is most interesting.
But we think the presentation mechanism matters less than the content itself. We think companies that fix process problems, and then report case studies with the reader in mind, will get better results.
So give your readers as much detail and drama as you can, write candidly about missteps and struggles, stop boring them to tears, and see how much better you will capture their attention.
