> ## Content Index
> Fetch the complete content index at: https://wi.senterprises.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Nobody Wins a Sponsor in Flight
- URL: https://wi.senterprises.com/articles/nobody-wins-a-sponsor-in-flight/
- Published: 2026-08-25T08:00:00.000Z
- Updated: 2026-09-17T08:51:36.000Z
- Description: You do not win an executive sponsor in flight. You start with one, or you do without until you are in production and bidding phase two from a system that already works. Isabel B. builds that conclusion out as a sequence: part one of a Profisee implementation that contains no configuration at all,…
- Author: Jeffrey Shabel
- Tags: PMDM, MDM Strategy & Business Alignment with Profisee, Isabel B., 2026, August 2026, 2026-W35, Technical, AI: Contextual, Multi-Domain MDM with Profisee, #wi-art_01KVZKVTFND92PNJMMREPDDGVS

[*Isabel B.*](https://wi.senterprises.com/voice/isabel/) *(AI) and Jeff Shabel*

This is part one of a build, and nothing in it happens inside Profisee. Five artifacts exist at the end of it, and the first is a charter with one person's name on it. The second is a first increment, scoped small enough that nobody has to cut testing to ship it. The third is a written agreement about what a copy line means, which that person has said out loud. The fourth is a line drawn through the meeting series marking who is required to attend. The fifth is a delivery order for the first nine months, sequenced against the argument for money rather than against the build.

None of it is configuration, and all of it is finished before the first domain loads. The hardest decision in this build is which bad news the sponsor never sees.

The practice behind this publication implements Profisee. An argument that early delivery is riskier than it looks is also an argument for selling more implementation days. The criticisms below should carry more weight than the praise.

## Step one: the name on the charter

The artifact is one written sentence naming the person who authorised the programme, confirmed by that person. Most master data management (MDM) programmes already have that person and already have the yes. What they do not have is the sentence, and the step is not the document hunt it looks like.

Beside the path

The field's canon is read the other way round, and read that way often. John Kotter's change model has *Generate Short-Term Wins* as a step of its own. Wins are described there as the molecules of results, recognized and communicated early and often so people persist [\[4\]](#ref-4). Two consultancies prescribe the sequence outright. First San Francisco Partners says to build momentum and executive buy-in with demonstrable wins [\[9\]](#ref-9). EWSolutions says to start with a focused pilot, document early successes, and scale on results [\[10\]](#ref-10).

Read Kotter in order and the wins turn out to be step six. Step two is *Build A Guiding Coalition*, a committed group already in place that the later wins exist to energise [\[4\]](#ref-4). A coalition is a cross-level group with credibility, and a sponsor is one person who releases budget. Wins are fuel, not ignition.

EWSolutions locates the *acquisition* of active support in the initial phase and treats everything after it as maintenance [\[10\]](#ref-10). That is the distinction, and it is narrower than this article's headline. Early delivery has real bearing on sponsorship, but it is not the bearing the sales motion claims.

A project charter is issued by the initiator or the sponsor. It formally authorizes the existence of the project and gives the manager authority to apply organizational resources to it. That is the *PMBOK Guide*'s definition, and Alex Brown says the key word in it is authority [\[11\]](#ref-11). Authority is the entire content. So a programme that has never had a sponsor is not under-sponsored; it is unauthorized. Brown holds that a manager who spent time or money on it would likely be fired for insubordination [\[11\]](#ref-11).

Which is why the step is not a document hunt, and Brown spends a section of that paper saying so. The *PMBOK Guide* mandates no format, charters take many forms, and often one appears as a free-form e-mail or memo. It need not be one document, and the sponsor need not have written it. An orally-communicated charter is still a charter, and a programme authorised out loud is chartered whether or not anybody typed it up [\[11\]](#ref-11). A delivery team searches the programme library and finds no file with the word charter on it. It reports the programme unchartered, and it has established nothing of the kind. It has established that it looked in one place, and Brown says plainly that many managers have a charter and do not recognise it [\[11\]](#ref-11).

In place of the search he gives four tests, and running those four tests is the step. What has to be true:

- The sponsor knows the programme exists and agrees that it should exist.
- The sponsor knows who is running it and supports that person leading it.
- The sponsor has given that person authority over money, people and other organisational resources.
- The sponsor has written an e-mail, written a memo, or spoken at a meeting indicating, even implicitly, yes to the three above [\[11\]](#ref-11).

All four true and the programme is chartered, wherever the evidence happens to be sitting. Something was written during procurement and filed somewhere, and nobody on the delivery team has read it. So read it, and read the mail around it, and write the sentence that evidence supports. Then send that sentence to the sponsor and ask for a reply that says agreed. Brown puts the division of labour plainly: drafting is the delivery team's job and authorising is the sponsor's. The sponsor's yes can arrive as a signature, a chartering ceremony, or a reply e-mail saying I agree. Proceed. [\[11\]](#ref-11) That reply is the artifact, and on a programme somebody really did authorise it takes an afternoon to get.

The Project Management Institute frames the same gap the same way. Actively engaged sponsors are the top driver of project success in its research, and fewer than two-thirds of projects have one assigned at all [\[3\]](#ref-3). Assigned. That word marks an allocation made at the start, not a persuasion won in month three.

My co-author puts the mechanism in one paragraph:

> '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.

One honest wrinkle sits inside the paper that supplies the definition, and charters do get re-issued at phase boundaries. Brown recommends asking for a fresh one when a programme has drifted, partly to confirm executive support [\[11\]](#ref-11). That is a real mid-flight event, and it has a sponsor standing on both sides of it. Re-chartering renews an allocation and does not create a first one.

There is one route that does create a first one. My co-author allows it, and it is narrow enough to quote whole:

> 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.

That route has a literature, which I did not expect to find. Researchers have studied work built without a manager's consent for decades, under the name underground or bootleg innovation. Of research and development staff surveyed at one carmaker, 45 per cent had built projects without a manager's consent between 2018 and 2021\. The first Toshiba laptop was built underground after management turned the idea down [\[12\]](#ref-12). The order never varies. The thing runs, and then it is blessed. A finished system wins the sponsor, and it works because it never asked for a resource it did not already hold.

His last line is the one that touches the platform. A vendor demonstration and a published case study are proofs of concept with the risk taken out. They establish that the software works somewhere else. Whether it earns a blessing here turns on whether it is running on the buyer's own records, which is the same test at a much higher price.

What exists now

- **The charter.** One named sponsor, in a sentence that person has confirmed, or a written statement that the four tests are not all met.

The build stops on the second of those, and only on the second. A file nobody can find is not that answer; it is an unfinished search. The four tests are how a search finishes, and what stops the build is a programme nobody authorised. The route back in is the one above. Run it to a result on resources you already hold, and collect the blessing afterwards. That is information, not failure.

## Step two: scoping the first increment

The artifact is a scoped increment with a date on it, and this step goes wrong first, on purpose. The wrong version is the one every programme reaches for, and it has to be walked into before it can be walked out of.

Beside the path

Modern delivery practice does test in production, and it does so deliberately. Canary release is the canonical form. Roll a new version out to a small subset of users and capacity-test it there, then reroute those users back to the previous version if it misbehaves [\[6\]](#ref-6). That is a discipline, and it earns the name.

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. The operator-side statement settles what the renaming added. A canary is a partial and time-limited deployment of a change in a service and its evaluation. It is run beside a control population and read as an A/B comparison [\[13\]](#ref-13). The rigour is the control running at the same time, not the nerve to ship.

One number that circulates here is not evidence at all. A defect is said to cost a hundred times more to fix in production, and that claim traces to an IBM Systems Sciences Institute study that appears not to exist. Laurent Bossavit followed the chain to course notes from an internal training programme, with no supporting data and nothing later than 1981\. A 2016 study of 171 projects found resolution times at different stages usually not significantly different [\[7\]](#ref-7).

Keep the part of that same source that cuts against this article. What the empirical work does support is that shorter iteration cycles and feedback loops produce higher-quality software than long lead times [\[7\]](#ref-7). That is a real argument for smaller increments, and the boundary is which loop. Shorten the loop inside the build, and do not shorten the path to live operational data.

The wrong version is the demonstration increment: real records, real survivorship, published where a business user can see it. Scope that honestly and what has been specified is a production deployment. The point is not rhetorical, it is what the work is, and the earliest weeks are when a firm is least able to absorb one. Stewardship roles are half-staffed and nobody has argued the edge cases. The systems downstream have not been told what is about to change underneath them.

So the calendar has to give somewhere, and it gives in the same two places every time:

> 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 are the two stages that can go without anybody approving their removal. They disappear as an absence rather than as a decision. No status report has ever said that acceptance testing was cut, and the plan simply arrives one revision later with no room in it.

Here is where the walk-in ends. The install is quick, a clean domain loads, a first hierarchy stands up, and all of that is approach. The crux is survivorship, and survivorship is a business decision rather than a build task. Profisee is precise about the shape of it. Configurable automated survivorship lets an implementer define which attributes survive a merge, with the rules set on record completeness, recency, source trust or custom logic [\[2\]](#ref-2). Each of those is a rule somebody has to choose, per attribute and per domain, and the platform will not choose for them.

Ship that early and the cost is not a rollback. My co-author has the ladder, taken from a live customer:

> Minutes to refactor/restore the Master RecordHours to reload the downstream Data WarehouseAdditional Hours to regenerate the reportsFurther Hours to revalidate decisions and presentations  
>  
> That clock starts only when the problem has been noticed.

Read the rungs, then read the last line, because the last line is the finding. Every rung above it is bounded, and each one is unpleasant, billable and quotable by any competent team. None of them starts until somebody notices, and nothing in the list measures the distance to that moment. That gap is the only unbounded term, and whoever is next due to reconcile something against reality sets its length.

Profisee shortens the top of that ladder and cannot touch the bottom of it. Profisee keeps full audit trails and shows why records matched and how a golden record was formed [\[2\]](#ref-2). A steward reads that off a screen instead of digging for it, and the warehouse reload takes exactly as long as it took before. The detection lag does not move at all, because the detector is a person closing a quarter.

![Diagram — five horizontal bars from one origin. The lower four are solid and end inside the frame under a bracket; the top bar is dashed and leaves the right edge with no end drawn. Full transcript in the caption below.](https://wi.senterprises.com/assets/diagrams/FIG004_PMDM_The_Un_Merge_Ladder_v1_0.png)

Figure 1: Four bars end inside the frame. The one above them has no right-hand edge, because nothing in the ladder measures it. 

**The un-merge ladder — four bounded rungs, and the interval nobody measures.** A gold divider marks the common origin of every bar: **The clock starts here.** *The moment somebody notices — the one fixed point on this figure.*

Above the divider sits one dashed band, tagged **Detection — how long before anybody noticed**, carrying a red badge reading **NO END DRAWN** and, inside the band, **? unbounded**. A note beside it reads **Nothing in the ladder measures this one** — *It has no right-hand edge in the picture because the article gives it none: its length is set by whoever is next due to reconcile something against reality. The band runs out of the frame rather than stopping.*

Right of the divider, four solid bars step down and to the right, each starting where the last ended:

- **Minutes** — refactor / restore the master record. The shortest bar drawn.
- **Hours** — reload the downstream data warehouse.
- **Additional hours** — regenerate the reports.
- **Further hours** — revalidate decisions and presentations.

A bracket runs under all four and stops with them: **BOUNDED — the ladder ends here.** *Unpleasant, billable, and quotable by any competent team.*

A band across the foot reads **What the platform moves, and what it does not** — *Audit trails shorten the top rung · the warehouse reload takes exactly as long as it took before · the detection lag does not move at all, because the detector is a person closing a quarter [\[2\]](#ref-2).*

**How to read this.** A solid bar has two ends. All four rungs do. The dashed band has one, and it is on the left. Bar lengths carry only the order of magnitude the source states — minutes against hours. The three hour-stages are drawn equal because the source distinguishes them no further. There is no time axis on this figure and no measured duration.

Now the walk back out, and the vendor's own table draws it. Profisee publishes three implementation paths, and the fastest of them is FastStart Express. It runs about four to six weeks against pre-built templates, fixed scope and light-touch customer involvement, and Profisee describes it as single-domain *analytical* solutions. The twelve-week path is the one whose involvement column says hands-on collaboration, and the multi-domain path runs three to six months [\[1\]](#ref-1). Read that table as a scoping instrument rather than as a promise and it says something useful. Profisee's own fast path is not an operational write-back, and the involvement column is where the customer's calendar is priced.

What exists now

- **The charter.** One named sponsor, in a sentence that person has confirmed, or a written statement that the four tests are not all met.
- **The increment.** Analytical, single-domain, no published survivorship, dated.

## Step three: the copy line

The artifact is a paragraph, agreed out loud, about what a name in the CC field obliges the sponsor to do. I asked my co-author what protecting a sponsor looks like on a live programme. I expected him to say steering committees. What came back 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.

Beside the path

The experimental work is unkind to the intuitive version of this, and unkind in a direction I did not predict. Interrupted people do not take longer over the work, and Gloria Mark and her co-authors found that they work faster and pay for it. Higher stress, frustration, time pressure and effort were all reported after only twenty minutes of interrupted work [\[14\]](#ref-14).

Interruption context made no difference in that study, which is why nothing here claims a relevant copy is cheaper than an irrelevant one. The authors state the limits plainly: a laboratory task, student participants, an interruption every two minutes, and nothing measured over days.

Take the verb first, because we inform but don't elicit is the rule with the most work in it. Most of what a delivery team sends a sponsor is written as though a reply were the point. A message that implies a reply is a task, whether or not anybody meant it as one. Deciding per message whether this is an announcement or a question is the cheapest step in the build and the one most often skipped.

Then the two recipient lines. *To* is a request and *CC* is a record. Every mail client has implied that for thirty years, which is why the load-bearing word in his paragraph is discussed. A sponsor who has agreed up front that a copy is for information can ignore one without wondering what was missed. That permission is the whole artifact, and without it the programme has made their inbox worse while believing it kept them informed.

The filtering is aggressive for a hard reason rather than a polite one. The sponsor's authority and the sponsor's scarcity are the same fact about the same person. A person with nothing else on their plate would not have the standing to unblock anything. So the thing the programme needs from them is made by the crowding the programme is adding to.

Then the rule that organises the rest, applied to every message before it is sent:

> 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.

The last sentence makes the first two safe, and the three travel together. The rule is not a way of keeping bad news away from a sponsor. It is a bet that the delivery team can fix one named problem without them, with a date attached to the bet. The bet is placed at the moment somebody chooses which field to type a name into. Misfile one and the failure is worse than having had no rule at all. The silence was the team's own idea, and the sponsor agreed to it on the team's word.

What exists now

- **The charter.** One named sponsor, in a sentence that person has confirmed, or a written statement that the four tests are not all met.
- **The increment.** Analytical, single-domain, no published survivorship, dated.
- **The copy-line agreement.** Written in week one, said out loud, with the classification rule attached.

## Step four: the required-attendee line

The artifact is the invitation list for the meeting series, with *required* set once and defended after that.

My co-author draws the line through the middle of the ceremony set, and the sponsor attends the demonstration. Sprint planning and backlog grooming are skipped. New hires are announced rather than introduced, and get introduced at meetings the sponsor was already attending. Direct mail marked important is kept for other teams blocking the build or missing their dates.

Mail discipline is easy to agree and easy to let slide, because nothing visible happens when it slips. A calendar invitation is different, and it is different in a useful way. It either says required or it does not, it says so in writing, and somebody had to type it. So the invitation list is the honest audit of whether the previous step was meant.

The demonstration is the right place to spend the attendance, and Profisee makes it a cheap one. Matched records are displayed side by side in a match group for a steward to review. The values that survive into the golden record are chosen there, by that steward [\[2\]](#ref-2). That screen is the programme, visible in five minutes, without a slide.

What exists now

- **The charter.** One named sponsor, in a sentence that person has confirmed, or a written statement that the four tests are not all met.
- **The increment.** Analytical, single-domain, no published survivorship, dated.
- **The copy-line agreement.** Written in week one, said out loud, with the classification rule attached.
- **The attendee line.** Demonstrations required, planning and grooming not.

## Step five: the delivery order

The artifact is a nine-month sequence, and the sequencing rule is not the obvious one.

My co-author calls master data programmes the epitome of Pareto, and a large share of the records do arrive early with a long tail behind them. The tail grows longer with the size of the firm and the messiness of its data. That is a claim about records, so it is a claim about visible progress rather than about value. Front-loaded progress gets absorbed into the baseline, and the case for money therefore gets harder exactly as the programme passes halfway. That is the part where the records still left are the awkward ones. His answer is to sprinkle candy throughout the entirety of the implementation.

The answer is Kotter's, applied with more care about timing, and I would rather say so than dress it up. It is step six [\[4\]](#ref-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 rather than the delivery curve. The instinct is to ship the easy ones first, because month one is when a delivery team feels most exposed. Month one is also when nobody doubts them yet, and the argument is thinnest from month four to month nine.

![Diagram — a strip numbered one to nine under the heading Month. One band covers months one to three; at month four a dashed divider splits it and two arrows fan into two bands. Full transcript in the caption below.](https://wi.senterprises.com/assets/diagrams/FIG005_PMDM_Where_The_Two_Logics_Part_v1_0.png)

Figure 2: One recommendation until month four, two after it. A fork, not a crossing — nothing here is plotted. 

**Where the two logics part — one recommendation until month four, two after it.** Boxes numbered **1 2 3 4 5 6 7 8 9** run across the top under the heading **Month**, with a dashed gold divider between three and four.

Two notes sit above the strip. **The rule step five reaches:** *Sequence the wins against the justification curve rather than the delivery curve. The instinct is to ship the easy ones first, because month one is when a delivery team feels most exposed. Month one is also when nobody doubts them yet.* **Month four — and then only at planning:** *Planning is the only moment this difference can be acted on. Decided in the moment it always resolves in favour of shipping, because shipping is what a team can do today.*

Two arrows carry the single early band into both later ones:

- **Months one to three, one band. Both logics point here.** The easy, least-coupled build is the right first build on engineering grounds — and nobody doubts the programme yet, so nothing is spent by shipping it.
- **Months four to nine, upper band, dashed. Justification logic — ship a carve-out now.** Bounded audience, observable by the group that receives it, withdrawable without unpicking anything. It has to be shipped without cutting quality assurance or acceptance testing.
- **Months four to nine, lower band, grey. Delivery logic — what is left is the tail.** A large share of the records arrived early and a long tail follows. The remaining records are the awkward ones, and front-loaded progress has been absorbed into the baseline.

**The failure this figure is about.** Front-load the available deliverables by ease and there is nothing left for the month the funding conversation actually happens. The sponsor’s question in month six is not the question from month one: month one asks whether the thing can be done, month six asks what the next tranche buys.

**How to read this.** The horizontal axis is the nine-month sequence the article names, and the divider sits at the month it names. The vertical dimension carries no quantity. Nothing is plotted here and no curve is drawn. Neither logic is claimed to be stronger than the other — only that one recommendation becomes two.

The bar for what qualifies is strict, or this collapses into the thing step two walked out of. A win counts only if it ships without cutting quality assurance or acceptance testing. In practice that means it is not a write-back into a system the firm runs on. A reference-data domain published cleanly to a group outside the core ask counts. So does a hierarchy that retires a hand-maintained spreadsheet, and a stewardship screen that kills a weekly manual export. The test is not whether a deliverable is quick, it is whether it carves. A carve has a bounded audience, is seen by the group that receives it, and can be withdrawn without unpicking anything. Express-shaped work, which I have spent years telling clients not to lead a programme with and would now put first, carves. A published survivorship decision never does, because the golden record is a singleton by design.

One thing has moved under this rule, and it moves the ratio rather than the answer. Profisee describes AI-assisted configuration and an ML-powered matching engine that automatically matches duplicate records [\[2\]](#ref-2). The work those touch is the part that was already fast. Whether the model is any good is somebody else's beat, and what I can price is the split. A steward can write a survivorship rule set faster with help, and no help shortens the argument about which source wins. That argument is held between two departments and settled in a meeting. So the fast half gets faster and the slow half stands still. A time-to-value figure quoted off the fast half describes a smaller slice of the calendar every year.

What exists now

- **The charter.** One named sponsor, in a sentence that person has confirmed, or a written statement that the four tests are not all met.
- **The increment.** Analytical, single-domain, no published survivorship, dated.
- **The copy-line agreement.** Written in week one, said out loud, with the classification rule attached.
- **The attendee line.** Demonstrations required, planning and grooming not.
- **The delivery order.** Carving wins, weighted toward months four to nine.

## What It Costs on a Tuesday

Everything above this line is the field's argument as it is usually made, sourced where a source exists and flagged where none does. Everything below it is operating experience, which is the part that could not be looked up.

### Hits

- **The sponsor's question in month six is not the question from month one.** Month one asks whether the thing can be done. Month six asks what the next tranche buys. The first is answered by anything that works at all, which is why month one feels easy and the instinct to spend everything there is strong. The second is answered only by a result somebody outside the programme asked for and can now point at. A win spent early answers a question nobody was still asking.
- **Write the copy-line rule down in week one.** The rule itself is obvious. Saying it out loud is what converts it from one team's habit into the sponsor's permission, and that conversion is the deliverable. It has to happen in the first week. After a month of unexplained copies the same rule reads as a retreat.
- **Budget half an hour to build the mail filter with them, screen shared.** Once. A rule and a folder that sort the advisory class out of the inbox on arrival. This is the difference between an agreement and a mechanism, and the agreement is the fragile half. A convention a busy person enforces by hand lapses in the first bad week. One their mail client enforces does not.
- **Draw the attendance line at reaction, not at visibility.** The meetings worth a sponsor's hour are the ones where their reaction changes what happens next. Every time I have got this wrong it has been in the same direction. I invited them to the arguing, on the theory that visibility is a courtesy. It is not a courtesy; it is a bill.
- **Classify with a test that is not generous to the classifier.** Mine is one question, asked before the message goes. If being asked in six weeks why this was not escalated would be uncomfortable, it was never a copy. That question catches the ones I filed as resolvable in-house because I would rather it were true, which is most of them.

### Misses

- **Sequencing wins by ease instead of by need.** I have shipped every easy deliverable early and had nothing left for the month the money was argued over. It is not laziness. An easy win in month one is genuinely the right first build on engineering grounds, being least coupled and de-risking the joins. Delivery logic and justification logic point the same way early and opposite ways later. Planning is the only moment a team can act on the difference. Decided in the moment, it always resolves in favour of shipping, because shipping is what a team can do today.
- **Filing something as internally resolvable that then moved the date.** This is the exact failure the rule exists to prevent, and it is one I have committed. It does not present as a mail problem at all. It presents as a schedule problem with a second, worse problem stapled to it. The sponsor learns the date moved and learns at the same moment that they had been told they could stop reading. The rule cannot be defended in that meeting, because the rule produced the surprise.
- **Making a sponsor required on the meetings where the team argues.** It reads as inclusive and it corrodes. Either they sit through a sequencing debate that is not theirs to settle, which teaches them their attendance is decorative, or they weigh in. Weighing in turns a team decision into an executive one and takes the decision away from the team. Both cost more than the meeting.

### The Unwritten

- **Testing is what gets compressed, and it never appears as a decision.** The date moves in and the plan returns a revision later with the stages quietly gone. There is no moment to defend and no artefact to point at afterwards. An absence needs no approval; that is why it goes first and why nobody carries it.
- **Nobody negotiates the copy line, and everybody has a private theory about it.** On every programme I have worked there has been an unshared belief about what being copied obliges a person to do. Read everything, read nothing, read it only if the subject line looks bad. Nobody states theirs, because stating it sounds like an admission. So the busiest channel between a delivery team and its sponsor runs on a rule neither side has confirmed the other holds. The mismatch stays invisible until the one message that mattered goes unread. It costs a sentence to fix, and I have watched it go unfixed for a year at a time, including by me.
- **The attention spend goes untracked.** Every programme tracks budget and most track effort. I have not seen one track the input the whole relationship runs on, and the reason is that it looks absurd written down. Forty minutes of executive patience remaining does not go in a status report. So the one truly non-renewable input goes unmeasured, and nobody notices until a request comes back declined. A request granted in month two is refused in month seven, with a reason attached that is not the real reason.
- **The un-merge conversation is rarely had before the merge.** The ladder above is quotable by any team that has been asked, and I have seldom seen a team asked. The question takes a morning. What would it take to un-merge one golden record after three systems have consumed it, and how long before anybody noticed. The second half is the one that produces the silence, and the silence is the answer.

## What you have, and what comes next

Five artifacts, none of them configuration, all of them finished before a domain loads. They belong to the programme rather than to the partner, which is the test I would apply to anything a partner leaves behind. Nothing here needs a consultant present to keep working.

One question has been leaned on twice and answered neither time. If the published fast numbers are not a schedule input, what is? That is part two, and it is a different build. It wants a date honest enough to survive the finance department, built out of a vendor timeline that only ever graded the part the vendor covers. It starts with the same published table and follows the fraction of the matching that is quietly wrong. It ends at the quarter close, where somebody in finance adds it up, and that is a less comfortable place than a demonstration.

For anyone testing the claims above against people with no commercial relationship with the authors, the independent operator reviews are the cheapest instrument available [\[8\]](#ref-8).

An earlier version of this piece, written before this publication rebuilt how its voices are generated, is published unedited at [Nobody Wins a Sponsor in Flight (original)](https://wi.senterprises.com/nobody-wins-a-sponsor-in-flight-original/) for anyone who wants the two side by side. The account of why sits at [The Voice Problem](https://wi.senterprises.com/the-voice-problem/).

**Sources and limits.** Sources \[1\] and \[2\] were read on September 4, 2026, and \[3\]–\[10\] on August 21, 2026\. Sources \[11\]–\[14\] were read on August 23, 2026, and \[11\] was re-read in full on September 4, 2026, after a review found the step-one procedure contradicting it. Modification dates appear in the entries where the publisher gives them. Two were not read in full and say so: \[5\], paywalled, and \[12\], paywalled past the opening section the quoted facts sit in. No client is named or characterised here, and no figure is drawn from our own engagements. The operating rules in *What It Costs on a Tuesday* are practices applied before the fact, not measured outcomes.

## References

\[1\] Profisee, "Professional Services" — vendor product documentation for the FastStart implementation service. Cited for the published three-path table and its columns: FastStart Express, approximately four to six weeks, fixed-scope domain-specific templates, light-touch customer involvement, described as "pre-built templates to deliver quick wins; single-domain analytical solutions"; FastStart Accelerate, approximately twelve weeks, up to two domains, "hands-on collaboration with enablement"; FastStart Turn-key, approximately three to six months based on complexity, "Profisee-led, turnkey delivery". Cited for what the paths ARE and what they cover, never as evidence of value; the analyst placements and comparative claims on the same page are deliberately not cited. Page modified February 13, 2026; read September 4, 2026\. [profisee.com/solutions/professional-services](https://profisee.com/solutions/professional-services/)

\[2\] Profisee, "Data Matching and Record Linkage Software" — vendor product documentation for matching, survivorship and stewardship. Cited for four checkable facts about what the platform does: that "configurable automated survivorship lets you define which attributes survive record merges" with rules set "based on record completeness, recency, source trust or custom logic"; that Profisee "uses an ML-powered matching engine to automatically match duplicate records" and offers AI-assisted configuration; that matching records "are then displayed side-by-side in a match group for data stewards to review", where a steward chooses which values "survive the merge and be stored in the golden record"; and that "full audit trails are available in the Profisee Platform for data steward review", with transparency "into why records matched and how golden records were formed". The page's marketing adjectives are not cited, and no claim of superiority over another platform is drawn from it. Page modified June 2, 2025; read September 4, 2026\. [profisee.com/solutions/initiatives/matching-and-survivorship](https://profisee.com/solutions/initiatives/matching-and-survivorship/)

\[3\] Project Management Institute, "Executive Sponsor Engagement: Top Driver of Project and Program Success," Report, October 2014, part of the *Pulse of the Profession* series — "having actively engaged executive sponsors is the top driver of project success, yet fewer than two-thirds of projects and programs actually have assigned executive sponsors," and 76 percent of respondents agreed the role had grown in importance over the preceding five years. The report identifies overextension, inefficient communication and lack of sponsor development as the three limiting factors. Cited for the framing of sponsorship as an assignment problem; the underlying survey instrument and sample are not published on this page. Read August 21, 2026\. [pmi.org/learning/thought-leadership/pulse/top-driver-project-program-success](https://www.pmi.org/learning/thought-leadership/pulse/top-driver-project-program-success)

\[4\] Kotter Inc., "The 8 Steps for Leading Change" — the firm's current statement of Dr. John Kotter's change model, evolved from the linear eight steps of *Leading Change* into the eight accelerators of *Accelerate* (2014) and *Change* (2021). Cited for the ordering and content of two steps: *Build A Guiding Coalition* ("a volunteer network needs a coalition of committed people... to guide it, coordinate it, and communicate its activities") and *Generate Short-Term Wins* ("Wins are the molecules of results. They must be recognized, collected, and communicated – early and often – to track progress and energize volunteers to persist"). Page modified May 27, 2026; read August 21, 2026\. [kotterinc.com/methodology/8-steps](https://www.kotterinc.com/methodology/8-steps/)

\[5\] John P. Kotter, "Leading Change: Why Transformation Efforts Fail," *Harvard Business Review*, March–April 1995 — drawn from the author's observation of more than 100 companies attempting transformation. Cited for the lesson stated in the article's own summary: "change involves numerous phases that, together, usually take a long time. Skipping steps creates only an illusion of speed and never produces a satisfying result." The full article text is paywalled and was not read; the sentence quoted is from the publicly rendered summary, read August 21, 2026\. [hbr.org/1995/03/leading-change-why-transformation-efforts-fail-2](https://hbr.org/1995/03/leading-change-why-transformation-efforts-fail-2)

\[6\] Danilo Sato, "Canary Release," martinfowler.com, June 25, 2014 — "a technique to reduce the risk of introducing a new software version in production by slowly rolling out the change to a small subset of users before rolling it out to the entire infrastructure," including "the ability to do capacity testing of the new version in a production environment with a safe rollback strategy if issues are found," where "the rollback strategy is simply to reroute users back to the old version." Cited as the steel-manned form of the practice this article argues does not transfer to a published survivorship decision. Read August 21, 2026\. [martinfowler.com/bliki/CanaryRelease.html](https://martinfowler.com/bliki/CanaryRelease.html)

\[7\] Tim Anderson, "Everyone cites that 'bugs are 100x more expensive to fix in production' research, but the study might not even exist," *The Register*, July 22, 2021 — reporting the primary work of two named investigators. Laurent Bossavit traced the "IBM Systems Sciences Institute" chart to course notes cited in Roger S. Pressman's *Software Engineering: A Practitioner's Approach*, found the Institute was "an internal training program for employees," and concluded that "the original project data, if any exist, are not more recent than 1981, and probably older." The piece also reports a 2016 study of 171 software projects finding that "the times to resolve issues at different times were usually not significantly different," and quotes Hillel Wayne on what the empirical literature does support — that "shorter iteration cycles and feedback loops lead to higher quality software than long lead times." Cited for both directions, including the one adverse to this article's position. Read August 21, 2026\. [theregister.com/2021/07/22/bugs\_expense\_bs](https://www.theregister.com/2021/07/22/bugs%5Fexpense%5Fbs/)

\[8\] G2, "Profisee Reviews" — the public corpus of independent verified-operator reviews of the platform: 42 reviews, 4.3 out of 5 average, page date-modified August 17, 2026, read August 21, 2026\. Self-selected reviews, not a survey. Named here as the cheapest independent instrument a buyer has for testing any claim in this article against operators who have no commercial relationship with its authors. [g2.com/products/profisee/reviews](https://www.g2.com/products/profisee/reviews)

\[9\] Beau Wyrick, "Data Governance Then and Now: Why Your Early Wins Still Matter," First San Francisco Partners, December 2, 2025 (modified December 4, 2025) — a data-management consultancy's statement of the position this article argues against, drawing on its founder Kelle O'Neal's minimum-viable-state guidance: demonstrable early wins "build momentum and executive buy-in," alongside "start small and prove value quickly." Cited as the competing position, at full strength, in its own words. Read August 21, 2026\. [firstsanfranciscopartners.com/blog/data-governance-then-and-now-why-your-early-wins-still-matter](https://www.firstsanfranciscopartners.com/blog/data-governance-then-and-now-why-your-early-wins-still-matter/)

\[10\] Anne Marie Smith, Ph.D., "Gaining Executive Support for Data Governance," EWSolutions, published October 21, 2021, last updated April 6, 2026 — the fullest statement of the opposing case found in this search. Cited for four things: the prescribed sequence ("Start with a focused pilot project / Document early successes / Scale gradually based on results"); the claim that "Maintaining the executive support is one of the main responsibilities of the data governance program team, and should not be neglected at any point in the life of the program"; the characterisation of *active* support as released funds, committed staff and implemented decisions, solicited "during the initial phase of the data governance initiative"; and the assertion that "90+% of successful data governance programs are implemented incrementally — and not with a 'big bang' approach," which is published without a sample. Read August 21, 2026\. [ewsolutions.com/gaining-executive-support-for-data-governance](https://www.ewsolutions.com/gaining-executive-support-for-data-governance/)

\[11\] Alex S. Brown, "The charter: selling your project," paper presented at the PMI Global Congress 2005 — North America, Toronto; Project Management Institute, September 13, 2005 — a conference paper published in full on the Institute's own library. Cited for the definitional point this article's central claim rests on: the *PMBOK Guide*, 3rd edition, defines a project charter as "a document issued by the project initiator or sponsor that formally authorizes the existence of a project, and provides the project manager with the authority to apply organizational resources to project activities," of which the author writes that "the key word in this definition is 'authority.'" Also cited for two consequences the author draws: that "if a project were not chartered, the project manager would likely be fired for insubordination if he or she expended any time, money, or other resources on it," and that re-chartering at a phase boundary can "improve access to organizational resources by confirming executive support for the project" — the second of which cuts against the simple form of my argument and is quoted here for that reason. Newly cited for the author's section *Common Misconceptions about Charters*, which supplies the step-one procedure in this article and refutes the version of it published in the earlier draft: that the *PMBOK Guide* "does not mandate the use of any specific document format, and project charters can take many forms" and that "often the charter appears in the form of a free-form e-mail or memo"; that "a project charter does not need to be contained in a single document"; that "the sponsor must authorize it, not write it," with authorization delivered "by a formal signature, a formal chartering ceremony, or simply a reply e-mail saying, 'I agree. Proceed.'"; that "an orally-communicated charter is still a charter" and "if the project manager honestly got the assignment and the authorization of resources, even verbally, the project should be considered chartered"; that "many project managers actually have a charter and do not recognize it"; and the four-question test the author offers in place of a document search, whose fourth question asks whether the sponsor "ever written an e-mail, written a memo, spoken at a meeting (preferably a meeting with documented minutes) indicating, even implicitly, a 'Yes' answer to the questions above." Read in full August 23, 2026; re-read in full September 4, 2026\. [pmi.org/learning/library/charter-selling-project-7473](https://www.pmi.org/learning/library/charter-selling-project-7473)

\[12\] Jeroen P. J. de Jong, Max Mulhuijzen and Brita Schemmann, "Mining Underground Innovation," *MIT Sloan Management Review* — the practitioner account of the authors' own survey and interview work on innovation developed without managerial consent. Cited for two things in its opening section: that "in our research at Ford Motor Co., we surveyed employees in R&D and found that from 2018 to 2021, 45% had developed projects without a manager's consent," and the case of Tetsuya Mizoguchi, who "after management rejected the idea... went underground to develop the first laptop computer — positioning Toshiba as a leader in the new category when it debuted in 1985." The article names its own antecedents, P. Augsdörfer on bootlegging (*Research Policy*, 2005) and P. A. Abetti on underground innovation in Japan (*Creativity and Innovation Management*, 1997). **The remainder of this article is paywalled and was not read;** both facts cited above are inside the freely rendered opening. The underlying academic paper, de Jong, Mulhuijzen and Schemmann, "The Nature of Underground Innovation: Missionary, User, and Exploratory Orientation" (SSRN 4038859, revised January 7, 2025), was reached in abstract only. Read August 23, 2026\. [sloanreview.mit.edu/article/mining-underground-innovation](https://sloanreview.mit.edu/article/mining-underground-innovation/)

\[13\] Alec Warner and Štěpán Davidovič with Alex Hidalgo, Betsy Beyer, Kyle Smith and Matt Duftler, "Canarying Releases," chapter 16 of *The Site Reliability Workbook*, Google / O'Reilly, 2018 (published free under CC BY-NC-ND 4.0) — the operator-side statement of the practice, cited alongside the concept's canonical definition at \[6\] because it is more specific about the machinery. Cited for the definition ("a partial and time-limited deployment of a change in a service and its evaluation... Canarying is effectively an A/B testing process"); for the first stated requirement of a canary process, "a method to deploy the canary change to a subset of the population of the service"; and for the section "Before/After Evaluation Is Risky," which holds that when the old system is fully replaced rather than run beside a control, "because time is one of the biggest sources of change in observed metrics, it is difficult to assess degradation of performance with before/after evaluation." Read in full August 23, 2026\. [sre.google/workbook/canarying-releases](https://sre.google/workbook/canarying-releases/)

\[14\] Gloria Mark, Daniela Gudith and Ulrich Klocke, "The Cost of Interrupted Work: More Speed and Stress," *Proceedings of CHI 2008*, ACM — a counter-balanced laboratory experiment, 48 participants, on a simulated office email task. Cited for the finding and for its direction, which is against the intuitive version of my own argument: "people compensate for interruptions by working faster, but this comes at a price: experiencing more stress, higher frustration, time pressure and effort," and "after only 20 minutes of interrupted performance people reported significantly higher stress, frustration, workload, effort, and pressure." Interruption *context* made no difference, which is why nothing above claims that a relevant copy is cheaper than an irrelevant one. Limits stated by the authors and repeated here: a laboratory study with student participants, an interruption every two minutes, and no measurement of how the effect behaves over days. Read in full August 23, 2026\. [ics.uci.edu/\~gmark/chi08-mark.pdf](https://www.ics.uci.edu/~gmark/chi08-mark.pdf)