Last week, we talked about managing master data during mergers and acquisitions. That kind of work puts pressure on everything at once: customer definitions, product structures, supplier records, ownership, and reporting logic. M&A tends to expose master data weaknesses quickly because two organizations are trying to operate together before their data is ready to support it.

This week, we stay on the strategy side of MDM and ask a question that sits underneath a lot of failed efforts: is this a project, or is it really a program? Many organizations fund MDM like a one-time fix, then wonder why the same issues come back after go live. This week’s article looks at that gap and explains why the answer affects much more than delivery.

MDM Project or Program? Choose Wisely

Most master data work does not start with a calm discussion about operating models.

It starts when something breaks hard enough to get attention.

A CRM migration is at risk because customer records are a mess. Product hierarchies keep wrecking reports. Finance and sales are using the same words for different things. Leadership sees two dashboards that should match and do not. Funding gets approved. A team gets formed. The work gets labeled an MDM project.

That is usually the entry point.

For a while, the project can look like real progress. Data gets profiled. Match rules get tuned. Duplicate records get cleaned up. A new hub or service comes online. A few key integrations are wired in. People get through cutover and finally stop holding their breath.

Then familiar problems start coming back.

A new source system arrives with different keys. Sales changes how it wants to group accounts. Finance still needs the legal hierarchy for billing and close. Operations exports data into a spreadsheet because the mastered view still does not answer the question they need answered. Reporting starts drifting again, usually quietly at first.

Most teams find this out after go live, not before.

That is the point where the real question shows up. You are not just choosing how to deliver MDM. You are deciding whether the work will be treated like a temporary fix or an ongoing business capability.

On paper, that can sound like a small distinction. In practice, it shapes almost everything that happens after launch.

Why the distinction matters

A project has a defined scope, timeline, team, and finish line. In MDM, that might mean building a customer master for a CRM rollout, standardizing suppliers ahead of ERP modernization, or cleaning product records for better reporting.

A program includes projects, sometimes several of them, but it does not stop when the first release is done. It assumes the business will change, source systems will change, new consumers will show up, and the data will need governance, stewardship, and maintenance long after the implementation team has moved on.

Starting with a project is usually fine. Trouble starts when the organization assumes the work ends there.

A project can get the first usable version into production. Keeping that data trusted after launch takes a different kind of commitment.

Why so many teams default to a project

The project model feels natural because most organizations are already built to fund visible delivery.

A project fits budget cycles. It creates milestones. It gives leaders something they can sponsor, track, and eventually mark complete. When a migration is already behind, or a reporting problem is creating noise, a project looks like the cleanest way to move fast.

Sometimes it is.

A narrow, urgent effort may need exactly that shape. If a company has to stand up a customer domain before a CRM cutover, a focused project may be the only practical move. The same goes for a product cleanup ahead of an acquisition integration or a supplier standardization effort before ERP go live.

Projects are good at creating movement. They pull people into the same room. They force decisions that might otherwise drift for months. They expose hidden issues. They reveal how many manual workarounds are hiding in reports, exports, and downstream tools.

That early momentum matters, especially in organizations that have ignored master data for years.

What catches teams off guard is how quickly master data spills past the edge of the original plan.

The work rarely stays inside the boundary

At the beginning, the scope sounds manageable.

Clean customer data for the migration. Align product records for reporting. Standardize supplier data so payment and procurement stop fighting each other.

By the middle of the work, the team usually finds the harder layer underneath.

Customer means one thing in sales and another in billing. Product categories in the ERP do not match what e-commerce needs. One source stores the legal parent. Another stores a regional sales rollup. A third stores neither in a way anyone fully trusts.

Finance may roll customers to the legal parent for billing and close. Sales may roll those same customers to a territory structure for quota and account coverage. Support may need a service hierarchy based on contract relationships. All three views can be valid.

That sounds manageable until the hierarchy rules collide.

At that point, the work is no longer just about cleansing records or building a mastered entity. It has become a continuing business problem about definitions, ownership, exceptions, and change. A project can expose that problem. It cannot keep those decisions aligned six months later.

What a project does well

This is worth saying clearly because teams sometimes swing too far the other way and start treating projects like the problem.

They are not.

Projects can be exactly what gets an MDM effort off the ground. They bring urgency. They make scope visible. They help organizations stop talking about master data in abstract terms and start addressing real pain.

A project can also create the first proof that the work is worth doing.

Maybe the business gets cleaner reporting before a board cycle. Maybe the CRM launch avoids a mess because duplicate accounts were handled early. Maybe supplier cleanup reduces payment delays and spend analysis becomes more believable. Those wins matter because they give the organization a reason to keep going.

In a lot of environments, you need that first visible success before anyone will fund the slower, ongoing work around stewardship and governance.

So the issue is not that teams start with a project. The issue is that many teams treat the first delivery as if it solved the whole category of problems.

Where project thinking starts to break down

Project logic begins to fail when the data is shared, long-lived, and tied to more than one important process.

That is where most master data lives.

If customer data feeds CRM, billing, service, reporting, planning, and compliance, the work does not end when the first mastered record is published. If product data affects ERP, warehouse operations, e-commerce, planning, and analytics, the first cleanup pass is only the beginning.

What happens next is usually slower and less dramatic than a failed cutover, which is why it gets missed.

Ownership gets fuzzy again. Source system conflicts return. Quality starts slipping one change at a time. Downstream teams rebuild their own logic because they cannot wait for enterprise decisions. By the time leadership notices, the issue is no longer just duplicate records. It is confidence.

This usually shows up first in reporting.

Finance sees one customer count. Sales sees another. Margin views change depending on which hierarchy got used. Someone in operations says the mastered product family does not match how the warehouse actually handles the item.

Now the business is back to asking which number is right.

A project can deliver a platform and still leave you in that spot.

What the difference looks like in practice

The contrast becomes clearer once the first release is behind you.

During implementation, most organizations know how to fund visible delivery. Budget gets approved for software, implementation support, data profiling, migration help, rule configuration, testing, and cutover. Those costs are easy to explain because they tie directly to a release.

The gaps usually show up later.

Steward time often gets assumed rather than funded. Governance support is treated like overhead. Issue management becomes something people are expected to squeeze in around their real job. Post-launch data quality reviews get delayed because the implementation team is already on the next priority.

Many teams can get money for the platform. Ongoing stewardship is where the budget usually gets thin.

The same pattern shows up in ownership. Delivery teams can carry the work through design and launch. After that, the questions get harder. Who approves hierarchy changes next quarter. Who resolves conflicts between finance and sales when both need a different customer rollup. Who decides whether a supplier exception is local or enterprise-wide. Who reviews the backlog when source systems keep creating new edge cases.

IT can own the platform. It cannot own the meaning of the data across every business process.

Success measures shift too. Project dashboards usually show records cleansed, interfaces built, sources onboarded, rules configured, and training completed. Useful metrics during delivery, yes, but they do not tell you whether the business still trusts the mastered data later.

The numbers that tell the deeper story often live somewhere else.

How many reports still rely on local customer mappings. How much time finance spends reconciling parent-child rollups before close. How many downstream systems bypass the mastered hierarchy and use their own logic. How long data issues sit unresolved. Whether duplicate rates fall for a month and then start climbing again.

Those are the measures that tell you whether the work is holding.

Example: the CRM migration that looked like a win

A company launches a customer MDM project to support a CRM migration.

The team profiles source systems, cleans a large batch of duplicate accounts, defines survivorship, maps records, and gets the new customer domain loaded into the target platform. The cutover goes well enough. Leaders are relieved. The project gets called a success.

Three months later, the cracks start to show.

New accounts are coming in with inconsistent parent-child relationships. Sales operations groups customers by regional account structure because that is how territory planning works. Finance still rolls those same customers to the legal billing parent because that is how close and revenue reporting work. Service teams need a contract-based view that fits neither of the other two cleanly.

All three views are reasonable.

What is missing is a durable way to decide which hierarchy supports which use case, how those structures relate, who approves changes, and how exceptions are handled when a customer gets acquired, split, renamed, or moved.

I’ve seen this happen when sales and finance inherit different parent-child structures and both assume theirs should drive the enterprise view.

So yes, the CRM project worked in one sense. The migration made it across the line.

The customer data problem did not disappear. It just changed shape.

Example: supplier data that slid backward

Supplier domains make this even easier to see because the impact tends to hit operations fast.

A company runs a supplier cleanup effort before ERP modernization. The team standardizes names, removes obvious duplicates, aligns identifiers, and improves the record set ahead of cutover. Accounts payable and procurement both see improvement.

Then new records start coming in from different systems and business units.

One supplier arrives with the same tax number but a different legal name. Another comes in under a local trade name. A third has one parent in finance and three separate vendor records in procurement because plants have been handling it locally for years.

You may find the same supplier under three names, two IDs, and one tax number. Procurement treats it as one. Finance does not.

Spend analysis starts drifting. Payment terms are inconsistent. Reporting gets noisier. Teams start debating whether the source is wrong or the master is stale.

That is not because the first cleanup was wasted. Cleanup alone was never enough. Somebody still needed to own match logic, exception handling, stewardship, and change review after the implementation team was done.

Without that, the data starts to slide backward a little at a time.

Funding tells you what leadership really believes

If you want a fast test for whether an organization sees MDM as a project or a program, look at what it funds after the first release.

A project budget usually covers the visible delivery pieces. Platform setup. Partner hours. Data conversion support. Rule configuration. Testing. Cutover. Real work, all of it.

But the expenses that protect the value of MDM tend to be less visible and easier to skip.

Steward time for customer or product issues. Governance support for change review. Someone to triage duplicates that keep coming in from new sources. Regular post-launch quality checks. Cleanup of metadata and mapping logic as systems change. These rarely get the same attention in the budget conversation.

When those items are missing, the organization is still funding a build, not a capability.

Then the tool gets blamed for decay that was really caused by the missing model around it.

Ownership is where a lot of efforts collapse

If nobody owns the data after release, the release is only a pause in the disorder.

Ownership is hard in MDM because the data cuts across functions. The platform may sit with IT. The business may claim ownership in principle. Yet when a real issue appears, the work often breaks into handoffs.

Sales says finance owns the hierarchy question. Finance says IT owns the system. IT says the source system needs to be fixed upstream. Operations says the issue is already affecting daily work and cannot wait for a governance meeting next month.

You can get away with vague ownership for a while. Then month-end close misses a number, a migration starts, or a merger forces questions the organization has been avoiding.

A project can assign task owners. A program has to define durable decision rights.

That means naming domain owners. It means designating stewards who have time and authority to work issues. It means setting clear escalation paths when two valid business needs collide. It means deciding who can approve change, not just who can request it.

Without that, even strong technical work starts eroding faster than teams expect.

Metrics reveal the mindset

Teams say a lot about MDM through the metrics they choose.

Project metrics tend to focus on completion. Records cleansed. Sources onboarded. Rules configured. Interfaces delivered. Cutover achieved. Training done.

All of that matters. It just does not tell you whether the mastered data has become part of how the business actually operates.

The more revealing measures tend to be messier.

How many finance reports still use local customer rollups before month-end close. How much time teams spend reconciling hierarchy differences by hand. How many downstream systems still ignore the mastered product family and keep their own classifications. How many supplier issues sit unresolved long enough that someone creates a workaround instead of waiting.

Those numbers are less flattering. They are also much closer to the truth.

A project can hit every milestone and still leave the business solving master data problems outside the master.

That is usually when leaders start saying the MDM effort “did not stick.”

The cultural part teams like to minimize

MDM is not only a design problem or an integration problem.

It is also a behavior problem.

People trust the logic they built themselves. Business units defend local definitions because those structures support how they plan, report, and get measured. Teams keep old workarounds alive because those workarounds have helped them survive past breakdowns. Source systems keep being treated as authoritative long after everyone knows they disagree with each other.

A project can work around that long enough to hit a release.

A program has to keep the organization from falling back into those habits.

That does not mean heavy governance theater. It means there has to be a durable way to make decisions, resolve conflicts, review change, and keep shared data from drifting back into a cluster of local truths.

Most teams learn this part the hard way. They assume the difficult work is technical. Later they find out the harder problem was getting the organization to keep acting like shared master data is actually shared.

What leaders should choose

For most organizations, the answer is not project or program.

It is project first, program next.

Start with a project when you need focus, urgency, visible progress, and a way to get funding tied to a specific pain point. Use that project to build the first useful slice of capability, expose hidden issues, and create a win the business can see.

Then use that same effort to establish the program model before the project winds down.

Define ownership before go live, not after. Identify stewards early. Agree on how change requests and exceptions will be handled. Set quality checks that continue after delivery. Plan sustainment funding while the project still has executive attention.

If those questions get pushed to the end, the organization is already behind.

A simple decision test

You probably need a program, not just a project, if most of these are true:

• the data is used across several systems
• multiple teams depend on the same core entities
• the domain affects reporting, workflow, compliance, or customer outcomes
• business definitions are already inconsistent
• new source systems or use cases will keep being added
• changes to the data require decisions across functions
• nobody can clearly say who owns the domain after implementation

If the work is truly narrow, isolated, and unlikely to need ongoing cross-functional decisions, a project may be enough for now.

That is not where most enterprise master data tends to live.

What leaders should ask right now

Some questions are worth asking before the next steering meeting:

1. Are we funding a release, or are we funding a capability?
2. Who owns this domain once the implementation team moves on?
3. What happens to issue resolution after launch?
4. Who approves hierarchy changes next quarter?
5. How many reports still rely on local remaps or manual fixes today?
6. What will we measure six months after go live that tells us the work is holding?

If the answers are weak, the organization is still in project mode even if everyone is calling it a program.

That does not mean the effort is failing. It means the next step is probably not more technical build work. It is putting the operating model in place before the data starts sliding backward again.

Final thought

MDM often has to begin as a project. That is usually the only practical way to get real momentum.

But if the data is shared, business-critical, and expected to stay useful across systems and teams, it cannot stay a project for long.

A project can get you to launch.

Most of the real MDM work starts when people assume the hard part is over.