Phone: 978-259-8429

It turns out that the standard “problem-solution-results” case-study formula doesn’t resonate with IT evaluators and decision makers. Similar to the general movement away from product- or company-focused collateral, today’s case studies need to impart practical information to technical prospects.

briefcaseA recent blog post by Scott Vaughan, VP of Marketing for TechWeb, highlights this issue. Scott gleaned his insights from a poll of CIOs, during which he asked: “What works and what do marketers need to do better?” The answers are enlightening.

Above and beyond discussing business goals, technology deployed, and outcomes, CIOs expect case studies to provide details about:

  • Options evaluated
  • Evaluation and implementation processes
  • Technology architectural approach

Technical evaluators also appreciate charts graphs, and time lines. But perhaps the most interesting finding is that technical folks want to understand how their own organization might approach a similar project. Essentially, they want to read about lessons learned. (Never mind success stories – as the CIO of Citigroup EMEA said, “…I already know the bloody ending. Why would I ever read it?”).

This insight is critical – and makes perfect sense. After all, a business-focused prospect wants to visualize how the solution will help him or her overcome business challenges. But the technology evaluator wants to see what it takes to successfully implement your solution.

One of my clients – SAP – is now satisfying this need by publishing Business Transformation Studies. So how can you as a technology marketer address this need? As Scott suggests, you need to rethink how you write and label your case studies and success stories. But the first step is to approach case study interviews from a new perspective. To make sure your case study will appeal to the technical crowd, ask the following during your interviews:

1. Describe your selection and evaluation process.
2. What were the key differentiators between our solution and others you considered?
3. Explain the implementation process, including key stakeholders, time line, number of users/locations, and organizational and/or business process changes.
4. Describe your technology environment before and after implementing the solution.
5. Share any governance processes, including escalations and change management.
6. Describe any end-user training or other initiatives that helped ease adoption.
7. What best practices did you employ during the project?
8. If you re-did the project, what would you do differently?
9. What three things must a company do to be successful with such a project?
10. What information resources did you find valuable during the course of this project?