On-Demand Webinar · 57 min

Building the Business Case for DataOps

Every data team knows DataOps delivers better analytics faster. Getting the rest of the organization to fund it is a different problem. DataKitchen CEO Chris Bergh and VP of Marketing Beth Pfefferle cover how DataOps builds on the staff and technology you already have rather than replacing them, how to construct the internal case, and how to collect the small wins that show its impact. Recorded January 2022; updated August 2026.

Presented by Chris Bergh

What you'll learn 7 points
  • The numbers behind the business case: Gartner puts 60 percent of data analytic projects as outright failures and says 87 percent of data science projects never reach production, DataKitchen finds 30 percent of companies have more than 11 errors a month, and 79 percent of teams want weekly therapy.
  • Gartner's 2020 figure is that only 22 percent of a data team's time goes to innovation and 78 percent to errors and manual execution. The 2022 DataKitchen and data.world survey adds that 52 percent of data engineers call errors a major source of burnout.
  • The ROI case has three separate calculations. Production errors cost team size times average salary times number of errors times percent of time on rework and triage, plus compliance risk and business opportunity cost. Downtime costs cost per outage times mean time to restore times change fail rate times deployment frequency. Lost productivity costs the time in unneeded meetings, context switching, waiting, and rework.
  • Published ratios of data engineers needed per analyst or data scientist range from 1:1 to 12:1. The claim made here is that DataKitchen flips it, with one data engineer supporting 12 analysts. Even a conservative 20 percent improvement across 10 people saves the equivalent of two people, which is more than the cost of the system.
  • One customer's before-and-after: cycle time to publish a new visualization went from weeks or months to next day, schema changes per data engineer per week from 1 to 12, analysts supported by one data engineer from 0.5 to 12, automated tests per build from zero to 1,000, and errors per build from frequent to none.
  • Rajesh Gill, former Celgene Senior Manager of Business Analytics, Forecasting and DataOps Strategy, reported errors dropping to about one per quarter when DataOps was first implemented, and several years without a major glitch after the team kept adding tests.
  • The advice on selling internally is to skip the DataOps explanation and show results instead: fix low-hanging fruit, publish metrics so everyone is accountable, establish a baseline before you claim improvement, and attach the work to an initiative already funded, such as a cloud migration, a data mesh, a data fabric, or a Snowflake purchase.

Prefer to read it? The written version is in The Business Case for DataOps.

Slides

56 slides

Questions from this session

How do you calculate the cost of production data errors?

Multiply data team size by average data team salary by the number of errors by the percentage of time spent on rework and triage. That gives the team time cost. Two more costs sit on top of it and are usually larger: compliance risk from wrong data, and the opportunity cost to business users who lose trust in the numbers and stop acting on them.

How do you calculate the cost of failed deployments?

Cost per outage, mean time to restore, change fail rate, and deployment frequency together give a cost of downtime per year. A deploy that fails without an outage still costs the team's time. One that fails with a data error or downtime costs the value of the data system not being available for as long as the restore takes.

How much of a data team's time goes to errors rather than new work?

Gartner's 2020 figure is 22 percent of time on innovation and 78 percent on errors and manual execution. A customer survey of its own data team found over 60 percent of team time was not value-added work at all, once meetings, context switching, waiting, and rework were counted. That overhead is the pool DataOps is meant to reclaim.

How do you sell DataOps to internal stakeholders?

Do not sell the details of DataOps, because most stakeholders do not care how the sausage is made. Fix low-hanging fruit for fast wins, publish metrics so everyone is accountable, and give leadership visibility into what is broken and why. Establish a baseline of cycle time, error rates, and where the team's hours actually go before claiming an improvement, and give the reporting time to stabilize.

Is DataOps just DevOps for data?

No. DevOps is a useful way to frame the conversation with IT, but DataOps is not only a CI/CD problem. It spans complex toolchains and multiple teams, and the outcomes it targets are error rates in production, cycle time of change, and team productivity rather than build and release mechanics alone. Oversimplifying it to DevOps loses most of what it does.

What is a DataOps maturity model assessment used for?

It assesses organizational readiness and produces a roadmap, which makes it a way to find the first project worth doing. It identifies weaknesses across error rates, cycle time, collaboration, team culture, measurement, and customer happiness. Those weak spots are where a short pilot has the best chance of showing a measurable result.

Where to go next