When I started working in data, I thought the hard part would be the technical work. I imagined data projects failed because of bad code, poor models, or complicated technology. After all, that's what most courses, certifications, and online content focus on. Then I joined DataSync.

Over the last year, I've had the opportunity to work alongside people who have delivered data projects at banks, asset managers, and large enterprises. Between them, they've spent decades fixing some of the most complex data problems in financial services. One thing surprised me. Almost none of their project horror stories started with technical problems. Instead, they usually started with conversations. Or a lack of them. The more projects I see, the more convinced I become that most data projects fail before a single line of code is written.

The Myth That Data Projects Are Technical Problems

If you spend enough time on LinkedIn, you could be forgiven for thinking data projects are primarily about technology.

The conversation is usually about:

• Which cloud platform to use
• Which AI model is best
• Which data stack is most modern
• Which coding language is fastest

These things matter. But they're rarely the reason a project succeeds or fails. One of the founders at DataSync once told me, “I’ve never seen a project fail because Python wasn't powerful enough. I laughed when I heard it. But after a year of hearing project stories, I understand exactly what he meant. Most organisations already have enough technology to solve the problem they're facing. What they often don't have is agreement.

Agreement on:

• What the problem actually is
• What success looks like
• Where the data comes from
• Who owns it
• How it should be defined

Without those answers, the technical work becomes an expensive guessing exercise.

The Project Starts Long Before the Project Starts

One story I heard involved a data transformation programme that had been running for months. The engineering team was delivering. The project managers were reporting progress. The steering committee was receiving updates.

Everything looked healthy. Until someone asked a simple question: "What exactly counts as a customer?" Different teams had different answers. Some counted legal entities. Some counted individuals. Some counted active relationships. Others counted historical records. Months of work had been completed before anyone realised they were measuring different things. The technology wasn't broken. The assumptions were. This isn't unusual. In fact, it seems surprisingly common. Many organisations rush into delivery mode because delivery feels productive. Workshops, requirements gathering, stakeholder alignment, and data discovery can feel slow. Writing code feels like progress. Unfortunately, writing the wrong code quickly is still going in the wrong direction.

The Real Job of a Data Analyst

This is probably the biggest lesson I've learned during my first year in the industry. Many junior analysts believe their job is to create dashboards, write SQL, or build reports. Those are useful skills. But they're not the job. The job is helping organisations make better decisions. That sounds obvious. But it changes how you approach projects.

A project-based data analyst spends more time asking questions like:

• What business decision are we trying to support?
• Who will use this information?
• What action will they take?
• What data definition are we using?
• What assumptions are we making?

When I first started, I thought asking lots of questions might make me look inexperienced. Now I think the opposite. The analysts who ask the best questions usually prevent the biggest problems.

Everyone Thinks They Agree Until They Don't

One pattern I keep hearing from experienced consultants is that stakeholders often believe they are aligned. Then the project begins. That's when the hidden disagreements appear. Marketing wants one outcome. Operations wants another. Risk has different priorities. Technology has different constraints. Data teams get caught in the middle. The challenge isn't usually finding data. The challenge is getting people to agree on what the data means. One founder described data projects as: "An organisational alignment exercise disguised as a technology project." The longer I work in this field, the more accurate that feels.

Why Junior Analysts Should Care

It's easy to think stakeholder alignment is somebody else's responsibility. The project manager's job. The programme lead's job. The consultant's job. But junior analysts often see issues before anyone else does. You're usually close enough to the data to spot inconsistencies. You notice when definitions don't match. You see duplicate fields. You discover conflicting business rules. Those observations are valuable. In fact, they may be more valuable than the dashboard you're building.

One of the best habits I've picked up is documenting assumptions early.

If someone says: "We define an active customer as..." Write it down.

If someone says: "This field is always populated..." Verify it.

Small questions asked early can save months of rework later.

The Hidden Cost of Getting Started Too Quickly

Most organisations worry about moving too slowly. Few worry about moving too quickly.

But starting before you're ready creates hidden costs:

• Rework
• Scope creep
• Stakeholder frustration
• Delayed delivery
• Loss of trust in data

Eventually the project gets labelled as a data problem. In reality, it was often a clarity problem. The data simply exposed it. This is one reason why experienced project teams spend significant time understanding the landscape before building anything. It isn't bureaucracy. It's risk reduction.

What I've Learned After My First Year

After spending a year around data projects, my biggest takeaway isn't technical. It's that successful projects create shared understanding before they create solutions. The organisations that succeed aren't necessarily the ones with the biggest budgets or the newest technology.

They're usually the ones that answer fundamental questions early:

• What problem are we solving?
• How do we define success?
• What data matters?
• Who owns it?
• What decisions will this improve?

Once those questions are answered, the technology becomes much easier. Not easy. Just easier.

Before You Write the SQL

If you're a junior analyst, here's the advice I wish I'd heard earlier. Before opening SQL. Before building a dashboard. Before creating a data model.

Ask:

• What decision is this helping someone make?
• Do stakeholders agree on the definitions?
• Have assumptions been documented?
• Does everyone share the same understanding of success?

Because by the time you're writing code, the most important project decisions may already have been made. And if they're wrong, no amount of technical excellence will save the project.

Why DataSync Exists

At DataSync, we've seen the same pattern repeatedly across data projects. Teams spend months building solutions while critical project knowledge remains trapped in documents, emails, spreadsheets, workshops, and individual people's heads. The challenge isn't simply moving data. It's preserving context.

DataSync helps organisations capture, structure, and maintain the business knowledge behind data projects—from requirements and definitions to lineage, mappings, and governance—so teams spend less time rediscovering information and more time delivering value. Because the fastest way to improve a data project isn't always writing better code. Sometimes it's making sure everyone is solving the same problem.

‍