Lessons from 20 Years of (Mostly) Successful Database Projects

After more than twenty years of delivering database projects, business systems, compliance platforms, reporting solutions and integrations, we’ve learned a simple truth:

Technology is usually not the reason projects succeed or fail.

Over that time, we’ve worked with organisations of all sizes. We’ve seen projects delivered on time and under budget. We’ve also seen projects that looked promising struggle to reach the finish line.

What we’ve found is that project outcomes are rarely determined by the choice of database, cloud platform, programming language or reporting tool.

More often, success or failure comes down to people, communication, leadership and organisational alignment.

Here are some of the most important lessons we’ve learned.

The Technology Is Usually Not the Problem

When projects fail, there is often a temptation to blame the technology.

Perhaps the database platform was chosen incorrectly. Maybe a different cloud provider would have been better. Perhaps the development framework was not ideal.

In reality, these factors rarely determine whether a project succeeds.

After twenty years of database projects, we’ve found that failed projects are far more likely to be caused by one of the following issues.

1. Unclear Requirements

The most common cause of project failure is uncertainty about what success actually looks like.

This can take many forms:

• Different stakeholders have different expectations.
• Business rules are not fully understood.
• Requirements are assumed rather than documented.
• Edge cases are discovered late in the project.

A development team can only build what has been clearly defined. When requirements are unclear, the project can appear to be progressing while the solution slowly drifts away from what the business actually needs.

We’ve learned that investing time upfront to understand workflows, decision-making processes and desired outcomes almost always saves time, money and frustration later.

2. Changes in the Business

Sometimes a project starts with clear requirements and strong momentum, only for the organisation itself to change.

Examples include:

• New management arrives.
• A merger or acquisition occurs.
• Budgets change.
• Regulations change.
• Business priorities shift.
• Key staff leave the organisation.

When this happens, requirements that were perfectly valid six months ago may no longer be relevant.

Some of our most challenging projects were not technically difficult at all. The challenge was adapting to a moving target while still maintaining momentum and delivering value.

Successful projects recognise that change is inevitable and build enough flexibility into the solution to adapt when business priorities evolve.

3. Loss of (or Never Having) Management Support

When leadership is engaged, projects move forward.

When leadership is disengaged, projects often stall regardless of how good the technical solution may be.

Management support provides:

• Clear priorities.
• Timely decisions.
• Budget certainty.
• Stakeholder accountability.
• Organisational momentum.

Without executive sponsorship, projects can become trapped in endless review cycles, competing priorities and conflicting stakeholder opinions.

In many cases, the technical work remains sound. The project simply loses the organisational support needed to reach the finish line.

Data Quality Matters More Than People Expect

Most organisations underestimate how much effort is required to maintain high-quality data.

It is common to hear statements such as:

“The data is mostly right.”

Unfortunately, “mostly right” is often not good enough.

Poor quality data leads to:

• Incorrect reporting.
• Poor business decisions.
• Loss of confidence in the system.
• Increased manual checking and rework.

One of the most frustrating outcomes for any project is delivering a technically successful solution that users do not trust because the underlying data is unreliable.

We’ve seen organisations spend significant amounts on new software, only to discover that the real issue was the quality of the information being entered into the system.

If users trust the data, they will use the system.

If they don’t, they will return to spreadsheets.

Keep the First Release Simple

One of the biggest mistakes organisations make is trying to solve every problem in the first release.

The enthusiasm is understandable. Once stakeholders become engaged, the list of desired features grows quickly.

Reports are added.

Integrations are added.

Additional workflows are added.

Before long, a project intended to take six months has doubled in size.

The most successful projects we’ve delivered focused on solving the most important problem first.

A solution delivering 80% of the value today is usually worth more than a perfect solution delivered years later.

Start small. Deliver value. Build momentum. Then improve.

Reporting Should Drive Design

Many projects treat reporting as something that can be dealt with at the end.

We’ve found the opposite approach works much better.

One of the first questions we ask is:

“What decisions will people make using this system?”

The answer often determines:

• What information must be collected.
• Which fields are mandatory.
• How data should be structured.
• Which business rules are required.

When reporting requirements are considered early, systems tend to be simpler, more effective and more valuable to the business.

When reporting is left until the end, expensive redesign work often follows.

Integration Is Harder Than Most People Expect

Modern businesses rely on multiple systems.

These may include:

• ERP systems.
• Accounting systems.
• Environmental monitoring systems.
• Laboratory systems.
• GIS platforms.
• Compliance management systems.
• Payroll systems.
• Government reporting platforms.

Connecting these systems is often more difficult than building a new application.

The technical connection is usually straightforward.

The challenge is ensuring both systems interpret the data in the same way.

What appears to be a simple integration project can quickly become a business rules project.

Over the years, we’ve learned that successful integrations require just as much attention to business processes as they do to technology.

The Best Systems Become Boring

This may sound strange, but it has proven true time and time again.

The most successful systems eventually stop being discussed.

Users stop complaining.

Support calls decrease.

Workarounds disappear.

People simply get on with their jobs.

Success is not measured by how exciting the software is.

Success is measured by reliability, trust and consistency.

When a business system becomes boring, it is often because it is doing exactly what it should be doing.

Relationships Matter

Technology projects are ultimately people projects.

Every project will face challenges.

Requirements will change.

Issues will arise.

Unexpected complexities will emerge.

When strong relationships exist between the client and delivery team, these challenges are usually resolved quickly and constructively.

The most successful projects we’ve been involved with were built on:

• Trust.
• Transparency.
• Open communication.
• Shared objectives.
• Mutual respect.

When clients and consultants work as partners rather than opponents, better outcomes almost always follow.

Final Thoughts

After twenty years of database projects, one lesson stands above all others:

Technology is rarely the deciding factor.

The choice between SQL Server, Azure, AWS, Microsoft Fabric, Oracle, PostgreSQL or any other platform is important, but it is seldom what determines whether a project succeeds.

Successful projects are built on:

• Clear requirements.
• Strong leadership.
• Organisational alignment.
• Trusted data.
• Realistic expectations.
• Effective communication.
• Collaborative relationships.

Technology continues to evolve at an extraordinary pace.

The fundamentals of project success have remained remarkably consistent.

The organisations that understand those fundamentals consistently achieve better outcomes than those chasing the latest technology trend.

The tools change.

The lessons rarely do.