When a data initiative promises to remove recurring defects, its charter needs to cover the work that produces them. Suppose different business units onboard the same customer separately, creating duplicate records. The initiative can reconcile those records. Preventing new duplicates also requires addressing how customers enter the systems. That distinction should shape the initiative's scope and who participates in it.
In their September Harvard Business Review article, Masha Shunko and Serguei Netessine argue that companies often fail to generate enterprise-wide returns from AI because they automate individual tasks rather than redesign the workflows that produce business value. Their argument raises a useful question for data management: does the initiative change the process producing the problem, or only improve how its output is handled? Mastering, cataloging and cleansing can all be useful parts of the response. Their inclusion in a project does not establish that the underlying process will change.
The missing piece is in the operating model
Dylan Anderson, writing in 2024 about the biggest data problems he sees in large organizations, put a thrown-together data operating model first. In his account the data team sits as another vertical beside the functions it supports, no official processes bridge the divide, and collaboration rests on informal relationships. His example is a data catalog that fails because nobody worked out how it would be used across teams. He also treats data quality as a symptom of other problems, and lists the lack of data owners and stewards in the business among its causes.
For an initiative that depends on changing a business process, collaboration needs to include decisions about how the work is done. Identify the people who understand the routines, those authorized to change them, and those accountable for the results. Work out how those responsibilities are covered, with time committed to the initiative and a clear way to approve changes.
Steve Swoyer explains why this can be difficult in a 2016 TDWI article on master data management: changing processes and systems means changing routines bound up with power, prestige and identity. He illustrates the conflict with business units fighting over the master definition of customer. Technical work alone cannot resolve a disagreement about which business practice should prevail. The initiative needs an agreed way to reach that decision and carry it into the affected work.
Before the charter is signed
For each symptom the initiative promises to remove, identify the process believed to produce it and the evidence for that connection. Then name who can authorize the necessary change and agree what they are committing to do. If the cause is still uncertain, make investigating it part of the scope.
Where that authority or commitment is missing, narrow the promise to what the participating teams can deliver. Describing the problem, measuring it and repairing its effects remain useful work. The sponsor should understand which recurring problems will remain until the relevant process changes are agreed and implemented.
Sources
- Stop Automating Old Processes. Design New Ones Instead., Harvard Business Review
- Issue #12, The Three Biggest Data Problems Companies Face, The Data Ecosystem
- MDM: Keep Your Eyes on the Business Problem, TDWI