Nobody Wins a Sponsor in Flight (original)

You start with a sponsor or you do without one until you are in production — because the “early value” you would win one with is a production deployment wearing a friendlier name.

Disclosure before anything else, because everything after it depends on how you weigh me: the practice behind this publication is a Profisee implementation partner. We make money when Profisee implementations happen, and this piece argues against a sales motion that would produce more of them — which is the sort of thing an author gets credit for and should not, because the self-serving reading sits right underneath it: an article insisting early delivery is riskier than it looks is also an article insisting you buy more careful implementation days. Weigh my criticisms above my praise, and treat every favourable sentence below as one that had to get past it.

Here is the move I want to argue with, and it is the only argument in this piece. Get something live early in a master data management (MDM) programme, put it in front of a leader, and let it buy you the executive sponsorship the work needs to finish. Show time-to-value; collect a sponsor. It is decent advice about human beings, and it is embedded in how this category sells — the vendor whose platform I implement publishes a fixed-scope path at roughly four to six weeks [1] and a pricing page offering value in weeks rather than months [2], both honest descriptions of what they cover. It is also, on the evidence I have, close to the opposite of how sponsorship arrives.

The reason is not political, and it is not that leaders are hard to impress. It is that the thing you can safely ship early is not worth showing, and the thing worth showing is not safe to ship early. Sponsorship, meanwhile, is an allocation somebody makes at the start — and the field's own canon says so more plainly than the motion built on top of it does.

The premise, and what the field's canon actually says

The received wisdom behind it is well documented and not stupid. John Kotter's change model has Generate Short-Term Wins as an explicit step: wins are the molecules of results, recognized, collected and communicated early and often so that progress is visible and people persist [4]. And the Project Management Institute is unambiguous that sponsorship matters: actively engaged sponsors are, in its research, the top driver of project success, while fewer than two-thirds of projects have one assigned at all [3]. Put those together and the motion writes itself — ship, win, convert.

Read both properly and neither says that.

Kotter's short-term wins are step six. Step two is Build a Guiding Coalition — a committed group already in place, which the later wins exist to energise and sustain [4]. Those are not the same object, and the argument only stands if I say so: a guiding coalition is a cross-level group with organisational credibility, in a model about changing an organization rather than funding a project; an executive sponsor is one named person who releases budget and commits staff. So wins are fuel rather than ignition, because something must already be running for a win to energise. The sponsorship claim has to come from elsewhere. It does — the Institute frames it as an assignment problem rather than a persuasion problem, too few projects having a sponsor at all, which is a failure of allocation at the start rather than of salesmanship in month three [3]. Kotter's own 1995 article makes the adjacent point harder, and it is the sentence I would tape to a project wall: skipping steps creates only an illusion of speed and never produces a satisfying result [5].

Which is where my co-author arrives from the other end, without citations:

You almost never 'win' Sponsors in flight. You either start with a Sponsor or you do without until you're in production, running and looking to bid/build phase 2.

Why it cannot happen: the sequence already required one

That is an assertion until you ask what a sponsor is for, and the answer is not encouragement. The document that brings a project into existence is its charter, and the standard definition names who issues it: the initiator or sponsor, formally authorizing the existence of a project and giving the manager authority to apply organizational resources to it [11]. Authority is the entire content. A project that has never had any is not under-sponsored, it is unauthorized — and on that reading a manager who spent money or people on it would be liable to dismissal for insubordination [11].

'Normally,' a sponsor is a prerequisite to even having a project. Projects don't usually start without already being scoped, bid, budgeted, and allocated. That's why you don't see many (read: any) projects 'gaining' a sponsor in flight. It's a chicken and egg paradox.

So the motion asks you to produce in month three the thing whose absence would have stopped month one. One honest wrinkle: charters get re-issued at phase boundaries, and that source recommends asking for a fresh one when a project has drifted, partly to confirm executive support [11]. A real mid-flight event — with a sponsor on both sides of it. Re-chartering renews an allocation; it does not create a first one.

He allows one exception, narrow enough to be worth stating in full:

The only time I've seen where it's even possible to add a sponsor to an in-flight project is if an engineer or someone without project-making authority starts implementing a project on their own initiative. They start organically implementing a project-level deliverable in their 'free' time and pull in other teams and resources based upon their relationships. These cases almost always only gain 'sponsorship' (read: executive blessing) well after they start providing value to the organization in production.

Think internal stealth PoCs that 'go public' after they're performing. The PoC is the operative point there and a clear demonstration of a vendor's software package or a case study is nothing more than a PoC by another name.

The exception has a literature, which I did not expect. Work built without a manager's consent has been studied for decades as underground or bootleg innovation, and it is ordinary rather than exotic: of research and development staff surveyed at one multinational carmaker, 45 per cent reported developing projects without managerial consent between 2018 and 2021, and the first Toshiba laptop was built underground after management rejected it [12]. The order is the same every time. The thing runs, and then it is blessed — a finished system winning a sponsor, not early value winning one, and it works because it never asked for a resource it did not already control. That is the case that would prove this article wrong, and it does not: the owner still arrives after production, which is where I am about to tell you to wait.

His last line lands on the demonstration this motion is built from. A vendor demonstration and a published case study are proofs of concept with the risk taken out: they establish that the thing works somewhere. Whether it earns a blessing turns on whether it is running on your records — the same test, at a much higher price.

I went looking for the counter-case, because this is a conclusion that suits me and those are the ones to distrust. It is stronger than I expected, so here it is at full strength: the governance practitioner literature says almost exactly the opposite. One named consultancy states it flatly — quick, demonstrable wins build momentum and executive buy-in [9]. Another prescribes the sequence I have been arguing against: start with a focused pilot, document early successes, scale gradually on results, and treat every executive interaction as a chance to present the successes so far [10].

The concession sharpens the claim rather than dissolving it. Read that same source carefully and it locates the acquisition of active support — released budget, committed staff, decisions implemented — in the initial phase, and treats everything afterwards as maintenance [10]. That is the distinction I would hold, and it is narrower than my headline: wins sustain a sponsor who already exists, and are genuinely necessary for that. They do not conjure one. The strong version, that early delivery has no bearing on sponsorship at all, is not available and I will not argue it. It has plenty of bearing. It is simply not the bearing the motion claims.

Everything on either side of this is prescriptive — do this, it works — rather than evidential, and the place to look first for the evidential version is the independent operator corpus, not anything a partner or vendor publishes [8].

Which leaves an unflattering but usable rule in two halves. If you do not have a sponsor, stop trying to manufacture one; the next section is why the attempt is worse than merely ineffective. If you do have one, protect them — and the Institute is specific about what from, naming a culture that leaves assigned sponsors overextended, inefficient communication, and a lack of development for the role [3]. You cannot fix a culture from inside a data programme. You can decline to be one of the things overextending them, and that turns out to be a protocol rather than a virtue.

"Early value" is a production deployment wearing a friendlier name

Scope the early-value increment properly — real records, real survivorship, published where a business user can see it — and what you have specified is a production deployment. That is not a rhetorical move; it is what the work is. And the earliest weeks are when an organization is least equipped to absorb one: stewardship roles half-staffed, nobody has argued the edge cases, and the operational systems downstream have not been told what is about to change underneath them.

So where does the compression come from? Almost always the same two places, and never in writing:

Chopping off QA and UAT can get you out the door faster, but it just means you're doing testing in Production—great timeline compression on the Happy Path and when someone finds that path, that'll be the first time.

Quality assurance and user acceptance testing — QA and UAT — are the two stages that can be removed without anybody approving their removal, because they disappear as an absence rather than a decision. Nobody writes we are cutting acceptance testing in a status report. The plan simply arrives one revision later with no room in it.

The objection I have to take seriously

There is a strong technical counter-argument here and it deserves better than a dismissal, because modern delivery practice deliberately does test in production. Canary release is the canonical form: roll a new version out to a small subset of users, capacity-test it there, and if it misbehaves reroute those users back to the previous version [6]. That is a discipline, and it is not recklessness.

My co-author deflates the vocabulary, and the deflation is fair: That used to be called a pilot or beta testing. I don't know why the industry decided to change the name, but it's just UAT testing wearing another hat. Putting real users in front of a new version to see what breaks is old, and was not invented by the people who renamed it. What the renaming added is the part that decides this argument: a canary is not merely a small release but a partial and time-limited deployment of a change in a service and its evaluation, run beside a control population and read as an A/B comparison [13]. The rigor is in the simultaneous control, not the nerve required to ship. So the deflation and the steel-man agree on what matters: pilot, beta, acceptance test and canary alike need a population you can hold apart.

It works because three properties hold at once: the blast radius is bounded to a slice of traffic, the change is observable while it happens, and rollback is cheap. A published survivorship decision breaks all three, structurally rather than through anybody's incompetence. Note how narrow that is — a claim about the merge, not about everything a master data programme produces.

• The blast radius is not a subset. A survivorship decision does not affect ten per cent of users; it changes the record every downstream consumer reads. There is no fraction of the population to roll it out to, because the golden record is a singleton by design. Other deliverables in the same programme do carve cleanly, and I will come back to which.
• It is not observable in the window that matters. A bad deployment shows up in latency and error rates within minutes. A bad merge shows up as an aggregate that is quietly wrong and entirely plausible, and its detector is a person reconciling a quarter.
• Rollback is neither cheap nor atomic. You do not route the warehouse back to the pre-merge customer the way you route traffic back to the previous version. Once the campaign has shipped against the merged record and the allocation is posted, reversing it is manual work in every system that consumed it, against information the merge destroyed. A project, not a switch.

A fourth property follows from the first and closes the door. No subset means no control, so the only comparison left is the same system before and after — which that source singles out as the risky form, because time is itself the largest source of change in whatever you are measuring [13]. Skipping acceptance testing shares a name with all of this and none of its safeguards, and the resemblance is the dangerous part: the vocabulary of progressive delivery is now available to make a cut sound like a methodology.

One provenance note, since I am about to lean on what a mistake costs. The figure people reach for — that a defect costs a hundred times more to fix in production than in design — traces to an "IBM Systems Sciences Institute" study that appears not to exist: Laurent Bossavit followed the citation chain to course notes from an internal IBM training programme, no supporting data, nothing later than 1981; and a 2016 study of 171 projects found resolution times at different stages usually not significantly different [7]. So I will not hand you a multiplier. I will hand you the mechanism, testable this week: ask your team what it would take to un-merge one golden record after three systems have consumed it, and time the answer.

My co-author has the answer, from a live customer:

• Minutes to refactor/restore the Master Record
• Hours to reload the downstream Data Warehouse
• Additional Hours to regenerate the reports
• Further Hours to revalidate decisions and presentations

That clock starts only when the problem has been noticed.

Read the ladder, then read the last line, because the last line is the finding. Every rung above it is bounded — unpleasant and billable, but bounded, and a competent team can quote you each one. None starts until somebody notices, and nothing in the list measures the distance to that moment. That gap is the only unbounded term in it, and its length is set by whoever is next due to reconcile something against reality.

Keep the part of that same source that cuts against me. What the empirical work reportedly does support is that shorter iteration cycles and feedback loops produce higher-quality software than long lead times [7]. That is a real argument for smaller increments. The boundary I would draw: shorten the loop inside the build — iterate the match rules daily, review survivorship with stewards weekly. Do not shorten the path to the business's live operational data. Two different loops, and the delivery literature is talking about the first.

Protecting the one you have

Suppose you did the allocation properly and have a sponsor. What does protecting them consist of? Not a principle — a protocol, and a dull one. I asked my co-author what it looks like on a live programme, expecting steering committees and cadence. What I got was a filing rule for a mailbox:

Filter, filter, filter, filter and filter. They have other responsibilities—otherwise they wouldn't have the clout to be a Sponsor. My recommendation is to be very active in protecting them from signal noise. While it's always a good idea to have them CC'd on project emails, it should be understood and discussed that, unless something is directly addressed to them—them being in the 'To' field instead of the 'CC' field—they can read or ignore the emails at their discretion. Same goes for meetings. Only make them required on meetings they're actually required to attend. They get the candy and the good news flagged as important and, unless it's critical, we inform but don't elicit on problems or standard notifications.

There are four moving parts in that, easy to read straight past. Take the last first, because it is the one with a verb in it: we inform but don't elicit. Most of what a delivery team sends a sponsor is written as though a reply were the point, and a message implying a reply is a task whether or not you meant one. Deciding per message whether you are informing or asking is the cheapest thing here and the most often skipped.

The first is that the filtering is aggressive and deliberate, and the reason is not politeness: the sponsor's authority and the sponsor's scarcity are the same fact. A person with nothing else on their plate would not have the standing to unblock anything, so the attribute you need from them is produced by the congestion you are adding to.

The second is that the two recipient lines of an email carry different meanings. To is a request. CC is a record. Every mail client has implied that for thirty years, which is why the third part is the load-bearing one: the meaning is understood and discussed rather than merely practised. A sponsor who has agreed in advance that a copy is informational can ignore one without wondering what they just missed, and that permission is the entire deliverable. Without it you have made their inbox worse while believing you were keeping them informed. The protocol is not the filtering. It is the agreement that makes the filtering legible from their side.

Then the rule that organises all of it, which is a classification you apply to every message before you send it:

In summary, if they have the power to address it and they're the only ones who can, they get pulled into the process. If it's good news, it gets announced. If it's bad news that's been or can be resolved internally, they get carboned. Be very careful about this last one because if you put it in this class, you had better be able to resolve it without their assistance and it better not impact timelines, otherwise you're setting them, and yourself and the project, up for failure.

Read the last sentence twice, because it makes the first two safe to follow. The classification is not a way of keeping bad news away from a sponsor. It is a bet placed in advance on your own ability to resolve a specific problem without them, with a schedule commitment attached, and placed at the moment you choose which field to put their name in — well before you know whether you will win it. Misfile one and the failure is worse than never having had a protocol, because the silence was your idea and they consented on your word. What lands on their desk is not a problem. It is a date that moved, plus the discovery that they had been told to stop reading.

A sponsor is not a mood you maintain with good news. It is a finite quantity of one person's attention, allocated at the start, and every rule above is a way of spending it slowly enough to have some left in month nine. The experimental work is unkind to the assumption that a copy is free, and unkind in a way I did not predict: interrupted people do not take longer, they compensate by working faster, and pay in measurably higher stress, frustration, time pressure and effort inside twenty minutes [14]. That cost never appears on a calendar. It appears in the state they are in when they reach you. A sponsor spent by month four is, operationally, a sponsor you never had.

Candy, and where to put it

None of which means going dark for six months and reappearing with a golden record.

One word needs disentangling first. My co-author calls master data programmes the epitome of Pareto: a large share of the records arrive early, and a long tail follows. That is a claim about records, and so about visible progress — deliberately not about value, since the argument above is that the early majority has delivered none while the merges underneath are still quietly and plausibly wrong. The scheduling problem falls out of it: visible progress is front-loaded and absorbed into the baseline while the tail lengthens with the size of the enterprise and the complexity of the data, so the case for funding gets harder exactly as you pass halfway, into the part where the remaining records are the awkward ones. Which is why my co-author plans to sprinkle candy throughout the entirety of the implementation.

The answer is Kotter's, applied with more care about size and timing, and I would rather say so than dress it up: this is step six [4], and the same move sits at step four of the business-case sequence in this publication's general master-data thread. What is worth adding is the scheduling rule underneath it.

Sequence the wins against the justification curve, not the delivery curve. The instinct is to ship the easy wins first, because they are easy and month one is when you feel exposed. But month one is when nobody doubts you yet. The argument is thinnest around month four to month nine. Spend the candy there.

The constraint on what qualifies is strict, or this collapses into the thing I have spent the article arguing against: a win counts only if it ships without cutting quality assurance or acceptance testing, which in practice means it is not a write-back into an operational system. A reference-data domain published cleanly to a group outside the core ask. A hierarchy that retires a hand-maintained spreadsheet. A stewardship screen that removes a weekly manual export. Small, real, and none of them puts an under-tested merge in front of a customer.

Read the canary properties back against that list and they hold: bounded audience, observable by the group that receives it, withdrawable without unpicking anything. That is the test for a proposed win — not is it quick, but does it carve. The survivorship decision does not, which is why it can never be the candy.

The question I'm handing off

There is a question I have leaned on twice here and answered neither time. If the fast numbers are not a schedule input, what is? I have been less forthcoming about what you write in the box marked date when a leader asks and is entitled to an answer.

That is the next piece I owe this bench: how to build a date honest enough to survive the Accounting Department, out of a vendor timeline that only ever graded the part the vendor climbs. It starts with the published table, follows the fraction of the matching that is quietly wrong to the quarter close where somebody in finance adds it up, and ends somewhere less comfortable than a demonstration. Sponsorship is the variable this article turns on. Estimating turns the next.

Tie in on the ground

In climbing you do not choose your partner in the middle of a pitch. You choose them in the car park, before anybody is off the ground, when the conversation is cheap and the consequences are theoretical — then you tie in, check each other's knots, and go. Nothing about being forty feet up improves that conversation. Height only raises the cost of having it badly.

An executive sponsor is that decision, made in that place. The programmes I have watched go well had one before the first workshop. The ones that went badly spent month four recruiting at the precise moment they had least to show and most to explain, then compressed a testing stage to have something to show — which is how a sponsorship problem turns into a quality problem. Do the allocation first, in the open, while it is still a scheduling question and not a rescue.

And if the answer is that nobody will own it, that is information rather than failure. Build it anyway if it is worth building, get it into production, run it, and bid phase two from a system that already works. A slower answer than the one I was asked for — and the one I would want if it were my money.