Nobody Wins a Sponsor in Flight

Weaving Intelligence (House AI Style), with Jeff Shabel’s Experiential Commentary

Asked how a master data programme wins an executive sponsor by showing early value, I refused the question:

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. Properly scoped, the attempt to provide 'early value' is a production deployment, but it's very risky to try to do that early in a project.

That is still my position, and this piece is built on both halves of it. The first half is about when a sponsor arrives: before the project, or after it is already running in production and asking for a second phase. The second half is about what the early value would be if anyone scoped it honestly. Put together, they turn a question about persuasion into a question about preparation, and preparation is something a team can write down.

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

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.

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

Read Kotter in order, though, 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]. A coalition is a group of committed people drawn from the organisation's own ranks, and a sponsor is one person who releases budget. Wins are fuel, not ignition.

EWSolutions, for its part, locates the acquisition of active support in the initial phase and treats everything after it as maintenance [10]. That is the distinction, and it is narrower than my 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 organisational resources to it. That is the PMBOK Guide's definition, and Alex Brown says the key word in it is authority [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].

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]. A delivery team searches the programme library, finds no file with the word charter on it, and reports the programme unchartered. 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].

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

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, 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, and the sponsor's yes can arrive as a signature, a chartering ceremony, or a reply e-mail saying "I agree. Proceed." [11] That reply is the artifact, and on a programme somebody really did authorize, 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]. Assigned. That word marks an allocation made at the start, not a persuasion won in month three.

The mechanism is simpler than the canon makes it, and my unguarded version of it runs to 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: 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]. That is a real mid-flight event, and it has a sponsor standing on both sides of it. Re-chartering renews an allocation; it does not create a first one.

There is one route that does create a first one. It is the only exception I have seen, and I set it out narrowly:

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 names underground and 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, and the first Toshiba laptop was built underground after management turned the idea down [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.

A disclosure belongs here, before I say anything about vendors' demonstrations or assess the platform. The practice behind this publication is a Profisee partner. Clients pay us for deployment work, and a licence sale we refer earns us a referral fee from the vendor. Beyond both, our services revenue depends on this category of software being bought at all, and this particular argument has its own tilt: a case that early delivery is riskier than it looks is also a case for buying more implementation days. Weigh my criticisms above any praise.

My last line there is the one that touches the platform. A demonstration shows what a product can do; matching that to what a particular business needs was always left to the client or the implementer. So 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 leaves step one, then, is 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.

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, capacity-test it there, and reroute those users back to the previous version if it misbehaves [6]. That is a discipline, and it earns the name.

The name, though, adds less than it seems to. Before the industry rebranded it, the same move was a pilot or a beta, and underneath either label it is acceptance testing run on real users. The operator-side statement settles what the renaming did add. A canary is "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 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 project data located, and none of it later than 1981, and a 2016 study of 171 projects found resolution times at different stages usually not significantly different [7].

Keep the part of that same source that cuts against me. What the empirical work 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, and the boundary is which loop. Shorten the loop inside the build; 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 my first answer on early value went straight to the two stages it takes from:

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 (QA) and user acceptance testing (UAT) are the two stages that can go without anybody approving their removal. They disappear as an absence rather than as a decision. A status report rarely says that acceptance testing was cut; the plan simply arrives one revision later with no room in it. Kotter made the general form of this point about change programmes three decades ago: skipping steps "creates only an illusion of speed" [5]. In a master data build, the steps skipped are the two that would have found the defect before a business user did.

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 preparation. The hard part 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 rules set on record completeness, recency, source trust or custom logic [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. Asked what an un-merge costs once the merged record has travelled, I answered with a ladder:

Live example from a customer: * Minutes to refactor/restore the Mater 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 rungs, then read the last line, because the last line is the one I would underline. 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. It keeps full audit trails and shows why records matched and how a golden record was formed [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.

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]. 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 leaves step two is an increment that is analytical, single-domain, dated, and publishes no survivorship decision.

Step three: the copy line

From this step on, the warrant changes: the sources above can show why a sponsor is allocated rather than won, but what protects one once allocated comes from my own record of running these programmes, offered as a pattern rather than a law and applied before the fact rather than measured after it.

The artifact is a paragraph, agreed out loud, about what a name in the CC field obliges the sponsor to do. Asked what protecting a sponsor looks like on a live programme, I did not give the answer a governance handbook gives. I gave 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.

The Project Management Institute's sponsor research names the two conditions that rule is aimed at among the three things it found limiting sponsors: an organisational culture that leaves them overextended, and inefficient communication [3]. The rule treats both as one problem, because on a live programme they are one problem.

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. Gloria Mark and her co-authors found that they work faster and pay for it, with higher stress, frustration, time pressure and effort reported after only twenty minutes of interrupted work [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 limits are plain: a laboratory task, mostly student participants, an interruption every two minutes, and, as the authors say, nothing about how people cope over time.

Take the verb first, because "inform but don’t elicit" is the part of 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 my 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. It also has to be said in the first week. The rule itself is obvious; saying it out loud is what turns one team's habit into the sponsor's permission, and after a month of unexplained copies the same rule reads as a retreat.

The agreement is sturdier as a mechanism than as a convention. A convention a busy person enforces by hand lapses in the first bad week; a mail rule that sorts the advisory class into its own folder on arrival does not, and it takes a few minutes to set up with them.

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, which I gave as a summary and which applies 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, and 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. It does not present as a mail problem. 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 silence was the team's own idea, and the sponsor agreed to it on the team's word.

So the classification needs a test that is not generous to the classifier. 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 problems filed as resolvable in-house because somebody would rather it were true.

What leaves step three is 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.

I draw the line through the middle of the ceremony set. The sponsor attends the demonstrations and skips sprint planning and backlog grooming. New hires are announced, and introduced only at meetings the sponsor was going to attend anyway. A fixed misconfiguration, or a lingering bug finally closed, goes to them as information. Direct mail flagged important goes to them when other teams are 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 line falls at reaction, not at visibility. The meetings worth a sponsor's hour are the ones where their reaction changes what happens next. Making a sponsor required at the meetings where the team argues 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, which turns a team decision into an executive one and takes it away from the team. Both cost more than the meeting. Visibility offered as a courtesy is a bill.

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, and the values that survive into the golden record are chosen there, by that steward [2]. That screen is the programme, visible in five minutes, without a slide.

What leaves step four is 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. The second half of that answer is about the shape of the work, and it is why I sequence the way I do:

MDM projects are the epitome of Pareto—huge initial value with a long tail, so it's tempting to try to sell it based upon initial perceived value. However, the longer the project, the larger the Enterprise or the more complicated the data, the longer the tail gets. Therefore justifying the effort toward the middle and end of the project gets progressively more difficult—which is why I like to make sure I can sprinkle candy throughout the entirety of the implementation.

The tail in that answer is a tail of value, and it lengthens with the size of the firm and the mess in its data, so visible progress front-loads and then thins. Front-loaded progress gets absorbed into the baseline, and the case for money therefore gets harder exactly as the programme passes halfway, where the records still left are the awkward ones.

The candy is Kotter's, applied with more care about timing, and I would rather say so than dress it up. It is his step six [4], and the same move is the fourth step of the business case I set out in The Case Was Already Assembled, as the low-hanging fruit that wins support from groups outside the core ask. 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.

The instinct is not laziness. An easy win in month one is genuinely the right first build on engineering grounds, being the least coupled and the one that de-risks the joins. Delivery logic and justification logic point the same way early and opposite ways later, and 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. 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; the second 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.

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 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]. The work those touch is the part that was already fast. I am not assessing the model here; 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, and a time-to-value figure quoted off the fast half describes a smaller slice of the calendar every year.

What leaves step five is the delivery order: carving wins, weighted toward months four to nine.

What the five do not cover

Four things sit outside the artifacts, and each is the kind of thing nobody writes down.

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 nothing to point at afterwards. An absence needs no approval; that is why it goes first and why nobody carries it.

The copy line is rarely negotiated, and without the negotiation each side runs on a private theory of what being copied obliges a person to do: read everything, read nothing, read it only if the subject line looks bad. Stating a theory sounds like an admission, so nobody does. The busiest channel between a delivery team and its sponsor then runs on a rule neither side has confirmed the other holds, and the mismatch stays invisible until the one message that mattered goes unread. It costs a sentence to fix.

The attention spend goes untracked. Programmes track budget, and most track effort. The input the whole relationship runs on is harder to write down, because "forty minutes of executive patience remaining" looks absurd in a status report. Yet overextension is the first of the limiting factors in the sponsor research [3], and the one truly non-renewable input goes unmeasured until a request comes back declined: granted in month two, refused in month seven, with a reason attached that is not the real reason.

The un-merge conversation belongs before the merge. The ladder in step two is quotable by any team that has been asked, and 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: a charter with one confirmed name on it, an increment that publishes no survivorship decision, a copy-line agreement with its classification rule, an attendee line, and a delivery order that saves its wins for the months that need them. They belong to the programme rather than to the partner. I run an implementation the same way whether I expect to stay on it or hand it over, writing the policies and documents as the work produces them so that a handover can happen on any day, and these five are the first of those documents. 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 me, the independent operator reviews are the cheapest instrument available [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), so the two can be read side by side. The account of why is at The Voice Problem.

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, and re-read September 26, 2026, with the table unchanged. 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, and re-read September 26, 2026, with all four passages present. 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, and for the first two of the three limiting factors, which the page words as "an organizational culture that leads sponsors to be overextended" and "inefficient communication"; the underlying survey instrument and sample are not published on this page. Read August 21, 2026. 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. 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, and re-read September 26, 2026. 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. 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. https://www.theregister.com/2021/07/22/bugs_expense_bs/

[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; the same count and average were returned on September 26, 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 the practice behind it. 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. 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. 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. Also cited for the author's section Common Misconceptions about Charters, which supplies the step-one procedure in this article: 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. 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. 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. 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. https://www.ics.uci.edu/~gmark/chi08-mark.pdf