With more than 12 years of being part of — and sometimes managing — data departments and projects, I've made a framework for ensuring the failure of a data department.

Why is this relevant?

• Too often, data projects fail to deliver what was expected.
• Too often, data departments experience massive employee turnover.
• Too often, data departments become isolated from the rest of the organization.
• Too often, data departments and projects fail catastrophically.

For most people, failures seem to come out of the blue. But they can be predicted. This article is written to help you anticipate — and in some cases, avoid — the failure of a data department.

Things can appear to be going well for long periods of time. However, without experience or knowledge of what can cause a department or project to crumble, there’s no real way to know what warning signs to watch for.

This article is meant to present the three fundamental things you must get right to avoid failure.

Let me start by defining what I call The Grace Period.

The Grace Period is the initial phase that begins when a department is founded, restarted, or when a new project kicks off.

During this time, the business and upper management expect little to no immediate delivery of business value. Any progress or value delivered by the team, no matter how small, is often celebrated as a major achievement.

This is extremely dangerous. It can mislead data managers into believing they are performing well, when in reality, disaster may be lurking just beyond the grace period.

If you've ever experienced the rollercoaster of initial success—only to find that, seemingly out of nowhere, the business (and particularly upper management) shifts, and suddenly nothing you do is good enough—then you've encountered this phenomenon firsthand.

I recommend that you use 'The Grace Period' to start with operational data.

I can not guarantee your success. But I can guarantee failure if you miss even one of the following three points.

• Deliver business value
• Deliver perceived business value
• Avoid slowdown of developer productivity

Being very good in one of them, will be a massive boost in how the organization sees you and your success. But if you are not a success in all of them, then being good at one of them, will only extend the grace period, but not prevent failure.

What constitutes business value varies across different companies.

However, there are a few common elements that every data department should deliver.

• Drill down on any measure to its lowest level.
• Clear and effective communication with business stakeholders.
• Trust in the data.
• A single source of truth.
• The business understands how to effectively use the data.

A failure to create business value is often first detected by operational teams at the lower levels of the organization. In many cases, higher-level management may go a long time before realizing the numbers are incorrect.

Perceived is the key word here.

In IT development, one challenge is that smooth operations often go unnoticed — if nothing breaks, no one remembers you're there.

This is why delivering business value alone is often not enough. You also need to ensure the business perceives that you are delivering value.

Perceived business value often eludes technical people, as there are very few technical solutions to shape perception.

Delivering business value, however, is essential. Without it, stakeholders will eventually turn against you — and you won't have internal allies to defend you.

The following strategies have worked well for me in enhancing perceived business value:

• Host regular weekly or monthly meetings open to the entire company.
  • Use these sessions to showcase your progress and highlight what your team has accomplished.
• The ability to drill down to the lowest level.
  • When someone's performance is judged by a KPI, they need to see how the numbers were calculated. Delivering a KPI without the ability to drill down into the underlying data and calculations is essentially gaslighting.
• Hold an in-person or online meeting with anyone requesting something from the data team.
• Do not add tasks to the backlog if they won’t be done. Clearly inform the requester if something is out of scope, and advise them on how to escalate the request if needed.

The slowdown in developer productivity is addressed in Carlsson's Productivity-Complexity Model