Getting a data warehouse over the finish line is hard. Data warehouses are complex organisms, requiring intense collaboration and technical expertise across every level of the organization. When it all comes together, it’s a beautiful thing. However, many data warehouse initiatives never make it to user acceptance.

On my technical blog, I have cataloged some of the reasons I’ve found that data warehouses fail. Avoiding these pitfalls can reduce the possibility of a data warehouse project going off the tracks. But things can still go wrong even with the best planning and adherence to best practices.

When Data Warehouse Projects Fail

The odds are good that something will go wrong during every data warehouse implementation: the due date for a deliverable gets pushed out, a dimension table has to be refactored, the granularity of a fact table changes. If things slide to the point that the project is no longer moving forward, it is critical to respond properly to get the project moving positively again if possible.

Triage

First and foremost, focus on determining status and next steps. Is the project truly ended, or has it just stalled? That distinction will drive most of the rest of the decisions made. If there is a design or development impasse, the road forward will look very different if the project has been shelved due to budget cutbacks or other factors. Assess if there is working room to salvage the project. If yes, use that time to isolate and minimize the speed bumps that slowed down the project the first time.

When triaging, don’t be afraid to issue an “all-stop” directive while you reassess next steps. However, don’t let the project founder in that state for long. Figure out what went wrong, fix it, and move forward.

Take inventory

Regardless of whether or not the project is salvageable, take stock of the individual deliverables and the respective status of each. If the project has simply stalled but the plug has not been pulled, having a clearly identified status of the technical and nontechnical assets will make the process of restarting the project far easier. If the project is not salvageable, there is almost certainly some business value in the work that has already been completed. Properly classifying and archiving those assets can provide a jump start for related initiatives in the future.

Communicate, communicate, communicate

Whether it’s a stalled project or one that has been stopped entirely, timely communication is essential to managing expectations. Clearly communicate the status of the project, what to expect next, and any timelines. Make sure that everyone involved – business analysts, executives, technical staff, and other stakeholders – is clear on the status and timeline. Don’t cast blame here; keep the updates fact-based and simple.

Renew the focus as a business project

For stalled data warehouse projects, it is important to refresh the focus of the project. Data warehouses should always be driven by business teams, not technical teams. Because of the technical complexities required of data warehouse projects, it is common to lose focus and steer data warehouse projects as technical initiatives. Although technical architecture is critical, the business stakeholders should be the ones driving the design and deliverables.

Scale back on deliverables

Of the reasons I’ve found that data warehouse projects fail, trying to do too much in one iteration is a common factor. Big-bang data warehouse projects don’t leave much flexibility for design changes or refactoring after user acceptance. If a stalled or failed data warehouse has many concurrent development initiatives, consider cutting back on the initial set of deliverables and deploying in phases. This can add overall time to the schedule, but you get a better product.

Bring in a hired gun

Insourcing your data warehouse project is often the right solution: you aren’t spending money on external help, you don’t lose that project-specific knowledge when the project is done, and your team gains the experience of building out the technical and nontechnical assets of the project. However, if a data warehouse project has stalled, bringing in the right partner to get back on track can help to save the project, and save time and money in the long run.

Conclusion

Like any technical project, data warehouse initiatives can stall or even fail. If this happens, it is important to properly set the project back on track, or wind it down as gracefully as possible if the project has been abandoned.