THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

The Rambling DBA: Jonathan Kehayias

The random ramblings and rantings of frazzled SQL Server DBA

Writing Case Studies to Document Your Impact

If you don’t know me, or you haven’t followed me for long, you might not know that I am a huge fan of documentation.  I started out in my as a Application and Business Analyst and all I did was document problems, their scope, impact, and resolution.  Early on I learned that one of the most powerful things you can create is good documentation for anything that you are involved with.  Even though I left my first job working with SQL Server over 4 years ago, I have on occasion received emails from the people that took over after I left asking me why certain design decisions were made, or why specific comments existed in code that I had written.  In a number of these cases I was able to ask a few questions and then tell them where to find the documentation for the specific feature, so that they could read through all of the information and then determine how to proceed with whatever issue they were working on.

When it comes to documentation, there are a number of different types of documents that can be created.  Most major projects have a Project Charter that provide the basis for the project.  In addition to this there are usually design documents, or specifications, that cover the technical aspects of the implementation.  There are project plans, meeting minutes, and a myriad of other documents that should get generated during the lifespan of a project.  One of the most important things about good documentation is that it survives beyond the scope of a given project as well as the tenure of a specific employee, and provides a key point of reference for the future if need be.  However, in my own experience, one item that rarely gets documented is a follow-up Case Study after the project ends, that documents the problem, the solution, and what benefits were provided by the implementation.  Until recently I never understood the importance of this final document in the grand scheme of things, but after a couple of my most recent projects, my Director requested that I write up Case Studies for how I had solved complex problems using SQL Server, and the impact that those solutions had on the daily operation of the business.

Case Studies are a very common marketing tool used by major technology vendors and consultants to provide a level of legitimacy to the services that they provide.  We have all seen them at some point in our tenures in IT, Microsoft has them, VMware has them, Quest Software has them, SQLSentry has themRedgate has them, in fact, all you have to do is search any major vendor name and Case Study in your favorite search engine, and you will find a link to their customer success stories.  Case Studies are a great marketing tool for vendors, they provide quantifiable validation of the impact that their products have in real world scenarios, and they can do the same for you as a data professional.

In today’s economy, it is more important than ever to provide justification for the things we do as data professionals.  One of the best things I get to do as a speaker, blogger, and member of the SQL Server community is talk to other people that do the same kind of work I do and that are passionate about the same things that I am passionate about.  In the last few years, I have found that in my discussions most people have had a hard time justifying the work they do, the need for new hardware, the need to upgrade their environments, and any number of other challenges in today’s workplace.  It dawned on me tonight after writing a couple of Case Studies for my own job, that we need to be vigilant as data professionals in justifying marketing our impact to the businesses that we support, and one of the best ways to do this is by writing up Case Studies for the projects that we have worked on.  For example, if you recently changed from a stand alone SQL Server to a SQL Server Cluster, which can be a significant expense to your employer, documenting the impact of that change in a Case Study can make it easier to justify similar upgrades in the future. 

So what exactly does it take to write a Case Study?  You might be surprised but its really a lot easier than you might expect.  If you click on any of the links provided above, you will probably notice that most Case Studies have three key things; they document the problem or business need, the solution implemented, and the benefits realized from implementing the solution covered by the Case Study.  These three things probably already exist in some form for any project that you have worked on recently or in the past, its just a matter of doing a little leg work and gathering them all together in a common document that highlights the successes of the project in a marketable manner.  A good Case Study doesn’t have to be complex, it can be as simple as;

Problem:  Users manually aggregated data using Microsoft Excel to generate weekly reports on efficiency.

Solution:  To alleviate the manual aggregation of data, reports were created using Microsoft SQL Server Reporting Services that handled the aggregations as a function of the reporting and automated the report execution through Reporting Service Subscriptions.

Benefits:  Automation of the aggregation of data saved roughly four man hours per week and the implementation of automated subscriptions ensures that accurate metrics are delivered timely regardless of employee staffing and vacation schedules. 

While this is an overly simplistic example, consider the potential marketability of this kind of information for a project that solved a ongoing reporting problem.  The odds are that in most businesses, this kind of problem isn’t isolated, and by providing a Case Study for how you solved one problem like this, the chances are, more work will come from it, leading to additional opportunities to solve, what are very basic reporting problems from a SQL Server standpoint, across the enterprise.  It is very possible, that after an initial project like this, the need will be realized for a dedicated reporting person, and the Case Studies generated will justify the need for an additional full time employee, or even a full time reporting team, spear heading a bigger BI project for the business.

Another benefit to writing Case Studies like this is that it can provide validation of your position and its impact to the business when the time comes for your annual review, which in the United States is often tied to your annual merit increase.  The ability to show a return on investment for your own position, as well as the projects that you have worked on during the past year, will most certainly put you on a stronger ground for negotiating a higher merit increase.  It is easier to ask for more pay when you can show through documented Case Studies, that your efforts to consolidate your SQL Server environment saved the company over $50K in Licensing and Software Assurance costs to Microsoft.

So my questions to you are this:

  • Have you ever written a Case Study for your efforts at work? 
  • If so have your realized any benefit from doing so?

Hopefully this blog post will motivate you to take the extra effort and document the impact of your efforts by writing up a few Case Studies based on the impact you’ve had in your own environment.

Published Wednesday, October 20, 2010 4:39 AM by Jonathan Kehayias



Oscar Zamora said:

This is a great Jonathan. You can always refer to the documentation to answer key questions like "why did we do this" or "what was the problem, etc. Now, the challenge is to figure out how to dedicate time to ensure that documentation is kept updated. There are shops out there that "exist, then think"

October 20, 2010 8:03 AM

Jian Hou said:

Good stuff. I have always told my fellow DBA team members that we need to promote the things we do and what we have achieved. Not so much as blowing our own horn, but to make them aware of us as a contributor to the company as well. I have never thought of doing a Case Study, but have considered drafting some documents to show what are the projets undertaken, the things achieved by the projects and the underlying value.

When doing these kind of documents, it's very important to include measurable metrics that the management can understand, doubly important if your boss is of non-IT background. Telling them that generating the TB report is now 45 seconds instead of announcing you increased the PLE counter to more than 5 minutes, will be far more easier for them to digest.

October 20, 2010 8:13 PM
Anonymous comments are disabled

This Blog


Privacy Statement