# Field Note: What I Have Seen in Projects Without Executive Support > Source: https://sukruyusufkaya.com/en/blog/saha-notu-yonetici-destegi > Updated: 2026-08-23T23:11:10.484Z > Type: blog > Category: yapay-zeka **TLDR:** What happens to enterprise AI projects without sponsor support? A field note on budget erosion, slowing decisions, resistance, and how to keep a project alive. This is a field note. I want to describe what I have seen over years of deploying enterprise AI projects, unembellished and reduced to a single pattern: the strongest variable determining a project's fate is often not how good the model is, but whether there is genuine sponsor support behind it. I have watched technically flawless projects fade out while technically average projects survived; the thing that most often explained the difference was this. This piece is written with a "case analysis" intent but contains no fictional company names, invented numbers, or embellished success stories. What I will describe is a pattern I encountered again and again, in different sectors and organizations of different sizes. What sponsor support is, what separates real support from nominal support, which signals appear when support weakens, and how I as a practitioner won and kept that support — I will convey all of it in the language of a field observation. Why devote a whole piece to this topic? Because the most expensive waste I saw in the field was the squandered effort of projects that were technically well built but had no real ownership behind them. A good team works for months, builds a solid system; then the project quietly stops though no one explicitly killed it. I watched this waste not once but many times; and each time I came back to the same root cause, weak or nominal sponsor support. This field note is written so that you do not live that pattern again. ## What Is Sponsor Support and Why Is It So Decisive? Sponsor support is something beyond an executive who signs off to start a project. By my definition, sponsor support is an active ownership that keeps providing the project with budget, priority, decision speed, and internal legitimacy. I underline the word "keeps," because the most common form of support's collapse is not its absence at the start but its erosion over time. An executive can be enthusiastic at the kickoff; the real question is whether they will still be there three months later when the first difficulty arrives. Why is an enterprise AI project so dependent on this support? Because these projects are as organizational as they are technical. Running a model is an engineering problem; but embedding that model into a business process, obtaining data access permission, changing another department's way of working, defending the budget, and preserving priority are entirely organizational problems. None of these is solved with code; they are solved only with the weight of an authorized executive. Executive ownership is the force that lets the project clear these organizational obstacles. Let me use an analogy. The technical team is the project's engine; sponsor support is the project's fuel and its permission to travel. Even the strongest engine will not move without fuel and cannot accelerate if the road is closed. The most tragic situation I have seen in the field was projects with a perfect engine that ran out of fuel and stayed on a closed road — the team does great work, but the project gets nowhere. This piece's starting point is exactly this observation: why do most good efforts die not for technical reasons but for support reasons? I cover the strategic frame of this topic in enterprise AI strategy, and the general picture of why projects fail in reasons for AI investment failure. This field note focuses on a single piece of that picture, perhaps the most decisive piece. ## Support Remaining in Name Only: The Pattern I See Most Often My most common observation in the field is this: support is rarely refused outright; most often it remains nominal. That is, on paper there is a sponsor, their name appears on the presentation slide, they attend the kickoff, they say "this is strategic for us" — but they do nothing that genuine ownership requires. This nominal support is more dangerous than the absence of support, because it misleads everyone: the team thinks it is supported, trusts the project, makes plans; yet the ground beneath is empty. Let me describe the behaviors by which I recognize nominal support. The executive shows interest in the project but gives it no time; when a calendar slot is requested they always say "I am busy this week." They constantly defer decisions; the phrases "let me think," "we will talk at the next meeting," "let me consult senior management" are the graveyard of decisions. They do not tie the project to their own goals; for them the project is a "nice to have," not a "must have." And the most critical test: at the first budget or priority squeeze, instead of defending the project they quietly withdraw it. Why is this nominal support so widespread? I have seen several reasons. Some executives say yes to AI "to not fall behind," but deep down have not understood what it is or why it matters; they cannot own it because they do not believe in it. Some genuinely want it but are not really ready to change their priorities; AI is one of dozens of items on a long list. Others put their name on the project out of a political calculation but do not want to bear the risk; if it works they take the credit, if it sinks they keep their distance. Whatever the reason, the result is the same: sponsor support exists in name, not in fact. An executive who openly says 'I do not support this project' actually does the team a favor: they clarify the situation, and the team either works to build support or redirects its energy elsewhere. Nominal support, by contrast, creates fog. The team walks for months thinking it is supported, makes plans, accumulates hope; then at the critical moment discovers the ground is empty. The teams most worn out in the field were not those without support but those deceived by nominal support. ## The Signs of Real Support: What Do I Look At? So how do I recognize genuine sponsor support? Over the years I have learned to rely on a few dependable indicators, and they all share one thing: not words but behaviors. Not what an executive says but what they do tells you whether there is support. The comparison table below brings together the strong and weak signals I have accumulated as field observations. The most decisive row in this table, for me, is "tying to a goal." If an executive has tied the project to their own performance target, their own annual commitment, the promise they made to their own boss, then that project is no longer a "nice to have" for them but a "must achieve." This is where real sponsor support is born. If an executive loses something themselves when the project is lost, that project is under strong ownership. If they lose nothing when it is lost, the ownership is not real. The second most reliable indicator is "clearing blockers." In every enterprise project there are doors that can only be opened with the executive's weight: a department's resistance, a data access permission, a legal approval, a budget line. An executive with real support clears these blockers personally and quickly; they see it not as a chore but as part of their own job. One with nominal support says "talk to the relevant unit" and dumps the matter on the team's back — yet the team has no authority to open that door. The most concrete proof of executive ownership is by whom the doors are opened. The third indicator is the bad-news moment. Every project produces bad news at some point: a delay, a lower-than-expected result, an unforeseen cost. This moment is support's litmus test. A real sponsor faces the bad news with the team, asking "what did we learn, how do we fix it." A nominal sponsor keeps distance when the problem arises, shifts to an "I was never sure anyway" tone, and leaves the team alone. Measure an executive's support not at the first victory but at the first bad news. ## The Commitment-of-Resources-and-Time Test The most practical way to test whether an executive's support is real is to look at the commitment of resources and time. Talk is cheap; resources and time are expensive. The more an executive ties their own time and their own budget to the project, the more real their support is. So one of the early questions I ask when joining a project is: "For this project, which resources have been committed, by whom, and for how long?" The time commitment is a signal even stronger than money. Because an executive's scarcest resource is their calendar. An executive who gives me regular, protected time — even fifteen minutes a week that they never cancel — is in fact proving their support. By contrast, an executive who defers every meeting, saying "I am very busy this week," whatever they say, has placed the project at the bottom of the priority list. The calendar does not lie; an executive's real priorities show not in what they say but in how they spend their time. The resource commitment is read similarly, but with a nuance: the concreteness of the commitment. "We will allocate resources to you" is a vague promise; "I am giving Ayşe to this project three days a week for the next two quarters" is a concrete commitment. The healthiest projects I saw in the field were those that clarified the resource by name, share, and duration. The most fragile projects were those where the resource was given "when free," that is, never really given. Resource withdrawal often begins right here, in leaving the commitment vague from the start. To tell whether a resource commitment is real, ask three things: who (name), how much (share, e.g. how many days a week), for how long (how many quarters). If these three are clear, the commitment is real. Expressions like 'we will support when needed,' 'we will look when available,' 'we will assign a team' are not commitments but polite forms of deferral. Getting these three clarities before starting a project prevents most of the resource-withdrawal surprises of the coming months. When this commitment test needs to be turned into a budget conversation, the frame in enterprise AI budget planning helps. Also, to defend the project's value in the executive's language, presenting an AI project to senior management and the AI investment board presentation give practical guidance on how to ask for the commitment. ## Effect on Decision Speed: The Most Measurable Output of Support Perhaps the most measurable output of sponsor support is decision speed. I have seen it many times in the field: in a supported project decisions come within days; in an unsupported one the same decisions wait for weeks, sometimes months. And this delay is the most insidious force that slowly kills a project. Because enterprise AI projects are built on speed; the faster the learning loop, the more value the project produces. When decisions slow down, the loop breaks. Let me make it concrete. In a project decisions constantly pile up: which data source will we use, which department will we pilot with, do we approve this budget line, do we accept this risk? In a supported project these decisions flow because the authorized executive acts fast; the team moves without waiting. In an unsupported project every decision enters an approval queue, the queue lengthens, the team waits. While waiting, motivation drops, the best people glance at other projects, and momentum is lost. The slowing of decisions does not look like a technical problem, but it collapses the project faster than technical problems do. Another dimension of decision speed is the quality of the decision. Slow decisions are often bad decisions, because as urgency accumulates the team pressures for "at least some decision," and the executive makes a hasty, insufficiently considered decision. Strong sponsor support, by contrast, makes decisions both fast and considered; because the executive already commands the topic and is not forced to decide abruptly. So decision speed and decision quality rise together when sponsor support is strong and fall together when it is weak. This connection also explains why projects get stuck in the pilot and cannot reach production. Under the "failure to move from pilot to production" problem I discuss in from PoC to production AI projects and the agentic AI pilot-to-production chasm, decision speed often lies; and beneath decision speed is sponsor support. I shared a broader field observation about projects stuck in the pilot in the field note on projects stuck in the pilot. ## Symptom × Root Cause × Prevention: A Diagnostic Table To read where a project stands in terms of sponsor support, I developed a diagnostic frame that ties the symptoms I observe to their root causes and preventions. The table below brings together the symptoms I saw again and again in the field, the real cause beneath them, and the prevention I saw work. You can use it as a diagnostic guide. The most important message of this table is this: symptoms should rarely be addressed on their own. Meeting cancellations, decision delays, and budget deferrals are most often different faces of the same root cause — weak or nominal sponsor support. Chasing each symptom one by one is tiring and fruitless; the real solution is to go down to the root cause, that is, the support relationship. When you suppress a symptom, as long as the root cause remains in place it returns as another symptom. The second message is that most of the preventions are relational, not technical. "Show an early win," "share bad news early," "make value visible with a business metric" — none of these goes through code; all go through the quality of the relationship built with the executive. The hardest lesson I learned in the field was this: even the best technical team lost its support when it neglected these relational preventions. I addressed this topic separately, in terms of the value non-technical roles add to a project, in non-technical roles and the AI champion. ## The Signals That Appear When Support Weakens The most dangerous feature of sponsor support is that it disappears not suddenly but slowly. No one says "we are closing this project" one day; instead support is withdrawn inch by inch and you look up to find the project has effectively stopped. So learning to read the early signals of weakening support is one of a practitioner's most valuable skills. If you notice early you can intervene; if you notice late you only attend the funeral. The first signal is the withdrawal of time. The executive begins to cancel meetings they used to attend regularly or sends someone in their place. Delegation is often a polite sign that interest has waned; the executive still says "I care" but is no longer there themselves. The second signal is the change in questions. The executive who at first asked "how do we do this better" gradually shifts to "how much does this cost," "when will it finish," "do we really need this." The shift of questions from techno-excitement to cost-concern is the clearest sign that patience is running out. The third signal is the thinning in the language of budget and resources. The sentence "we are investing in this project" turns first into "let us manage for now," then into "we will look again next quarter." Resource withdrawal usually comes in this gentle guise of deferral; no one says "I am cutting the resource," only "it is not available right now." One team member being shifted "temporarily" to other work and never returning is the classic form of resource withdrawal. The fourth signal is the loss of visibility: the project no longer appears in the executive's presentations to senior management, its name is not mentioned in corporate communications, it is pulled from the "showcase." When these signals come together, a project fade-out has begun. A project fade-out is not a sudden death; it is priority erosion, resource withdrawal, and slowing decisions combining to slowly stop the project. Its most insidious feature is that no one takes responsibility: the project is not "cancelled," only "suspended," "put on hold," "re-evaluated" — and never returns. I also addressed this silent-fade pattern, with its reflection on the adoption side, in the field note on user adoption. Most of the projects I saw in the field did not die with a 'cancel' decision in a meeting. Far more common was this: the project fell off the agenda one day, resources were withdrawn one by one, decisions piled up, and six months later no one spoke of that project. No one admitted killing it because no one had made a single 'kill decision.' So the way to prevent a project fade-out is not to wait for one big threat but to read the small signals early and respond to each immediately. ## Finding a Sponsor: How Do I Choose the Right Executive? Before keeping support comes finding the right sponsor. A mistake I saw in the field is the "make the topmost person the sponsor" reflex. The highest-titled executive is not always the best sponsor; because the topmost person's agenda is the most crowded and their real time for the project is the least. The single criterion of a good sponsor is not title but the intersection of authority, interest, and accessibility. When seeking the right sponsor I look at three things. First, authority: does this executive truly have the authority to make the decisions the project will need (budget, resources, priority, process change)? Second, interest: does this project touch this executive's own goals? An executive solving their own problem is a far stronger sponsor than one thinking "it would be good for the organization." Third, accessibility: will I be able to reach this executive regularly, or will I wait weeks for each meeting? A sponsor who has authority but is never reachable looks good on paper but is useless in practice. At the intersection of these three criteria, what usually emerges is not the topmost person but "a strong executive one level down": someone who has the authority to make the decisions, whose own goal intersects with the project, and who is accessible enough to give you regular time. In the field the sponsors of the most solid projects usually fit this profile. Keeping a senior executive (C-level) in the background as a top supporter is valuable; but the real sponsor carrying the daily execution is often one level down. Another critical point: not reducing the sponsor to a single person. A project tied to a single sponsor is defenseless when that person leaves or their priority changes. So the ideal setup is a lead sponsor plus a steering group supporting them. This group both legitimizes decisions and distributes the risk of single-person dependency. To build the right role and ownership structure, AI organization design and the Chief AI Officer role definition offer a frame for how to build this structure at enterprise scale. ## Tactics for Winning Support: What I Learned in the Field After finding the right sponsor comes the truly hard part: winning support and keeping it over time. There is no magic formula for this; but there are a few tactics I saw work again and again in the field. Their common denominator is seeing support not as a one-off approval but as a continuously nourished relationship. First tactic: speak business outcomes, not technology. Explaining the model's architecture, embeddings, or token cost to an executive almost never strengthens support; because the executive does not speak this language and this is not their problem. Their problem is cost, speed, customer satisfaction, risk, and growth. When I learned to translate the project into this language — "this shortens the support team's resolution time," "this reduces compliance risk" — I saw how support strengthened. The executive invests not in technology but in their own goal. Second tactic: produce early and small wins. The promise of a big result months away tests patience and invites the erosion of support. Instead, showing a visible, concrete, modest improvement within a few weeks renews the executive's support and buys you time to move forward. What I learned in the field was this: a small but real win is always more persuasive than a big but distant promise. An early win is the fuel that feeds support; without it even the best projects starve and fade out. Third tactic: make the executive a partner, not a spectator. Take decisions together with them, report progress regularly and honestly, and — this is critical — give bad news early too. Teams that hide bad news lose the executive's trust wholesale when the problem erupts; teams that bring bad news early and with a proposed solution accumulate trust. If an executive feels a real partner in the process and knows they are honestly informed, they stand by the project in hard moments. Support grows with honesty. The teams that best preserved their support in the field shared three habits. First, going to every executive meeting with a business outcome and a clear next step. Second, delivering the promised small win on time — trust is built from small promises kept. Third, making sure the executive is the first to hear the bad news; executives who hate surprises are grateful for early warning. These three habits won more support than writing the best code. To turn these tactics into a systematic presentation and persuasion language, presenting an AI project to senior management; to defend the project's value with numbers, how to calculate AI ROI; and to assess the organization's overall AI maturity, how to build an enterprise AI strategy complete this field note. ## What Can Be Done When Support Is Weak? Realistic Options We do not always start under ideal conditions. Sometimes you find yourself inside a project whose sponsor support is weak from the start. What to do then? I have seen a few realistic options in the field, and none of them is "carry on heroically without support." Support-less heroism was the strategy that most often led to burnout in the field. First option: narrow the scope and build support. If there is no support for a big transformation, you can start with a small, low-risk win and turn that win into support. Expecting a big commitment without showing the executive a concrete result is unrealistic; but a small success can open the door to big support. This is the "earn trust first, then ask for scale" strategy, and it requires patience but works. To narrow the scope correctly, the AI use-case prioritization matrix is a useful tool. Second option: change or elevate the sponsor. If the current sponsor is truly indifferent and will not change, moving the project to another executive closer to its goal or more curious about the topic is sometimes the only solution. This is politically sensitive but, as I saw in the field, far less wearing than trying to carry on with the wrong sponsor. The right sponsor changes the project's fuel without changing its engine. Third option — and the hard one to say — consciously pausing or closing the project. If neither support can be built nor the right sponsor found, forcing that project, however technically good, wastes the team's energy and the organization's trust. The maturity I learned in the field was this: sometimes the most correct decision is to honorably stop an unsupported project and redirect the energy to a supported one. Stopping a project in time is not failure but resource discipline. In the decision of whether to proceed with an internal team or get external help, AI consulting or an internal team helps. ## My Frequent Observations and Common Mistakes The field observations accumulated over the years point to a set of recurring mistakes. Listing them one by one may help you look for early warning signs in your own project. All of them arise from misunderstanding or neglecting sponsor support. The mistake I saw most often is mistaking the initial excitement for support. The enthusiasm at the kickoff is real but temporary; real support is measured in the third month when the first difficulty arrives. Teams often trust the initial enthusiasm and assume the ground is solid; then at the first tremor they see the ground is empty. The second mistake is looking for support on paper: the sponsor box in the org chart is filled, but the person in that box does nothing in fact. The chart does not show support; behavior does. The third mistake is hiding bad news. Teams defer problems so as not to disappoint the executive, saying "we will handle it"; and when the problem grows and erupts, the executive faces both the bad result and the concealment, and trust is lost twofold. The fourth mistake is over-dependence on a single sponsor: the project stands on one person's shoulders, and when that person leaves or their priority changes, the project collapses. When support transfer is not planned, a sponsor change is often the end of the project. The fifth mistake is refusing to speak the executive's language. The technical team falls in love with the solution's elegance and wants to explain it to the executive; yet the executive cares not about elegance but about results. Teams that refuse to translate technology into a business outcome lose support even if they do the best work. The sixth mistake is choosing the wrong executive as sponsor: automatically making the highest-titled person the sponsor but not seeing that this person has neither the time nor the real interest. A sponsor who has authority but is unreachable, however good on paper, keeps the project waiting in the decision queue; and this slowly leads to a project fade-out. The seventh and perhaps most insidious mistake is ignoring the signals of weakening support: mistaking cancelled meetings for "busyness" and a deferred budget for "temporary," and refusing to read the early warnings. Teams that do not read these signals early notice resource withdrawal only at the point of no return. All these mistakes are in fact different faces of a single root fallacy: thinking of support as something obtained once and set aside. Yet sponsor support is a living relationship that dries up if not continuously nourished. Let me say it as a field observation: the teams that made these mistakes were not bad teams; most were technically very good. They just realized late that enterprise AI is not a technology affair but an ownership and relationship affair. I gathered the broader reflection of these patterns in transformation projects in the field note on transformation patterns. ## The First 90 Days: The Real Test of Sponsor Support A project's fate in terms of sponsor support is often decided in the first ninety days. These first three months are the critical window in which the initial excitement slowly turns into real ownership — or fails to and fades out. As far as I have seen in the field, ninety days is enough to tell whether an executive's support is real or nominal; because in this period the first difficulty, the first bad news, and the first resource conflict inevitably occur, and support is tested in these three fires. In the first thirty days most executives look supportive; in this phase no difficulty has yet arisen and no sacrifice has been asked of anyone. The real test begins in the second month: the project meets its first technical or organizational obstacle, and whether the executive personally clears it becomes visible. In the third month the first bad news arrives — a delay, a lower-than-expected result, or an unforeseen cost — and the executive either faces it with the team or keeps distance. How these three moments pass draws the map for the rest of the project. So as a practitioner I learned to manage the first ninety days consciously. From the first month I aim for a small but real win; because the strongest fuel that feeds an executive's support is a concrete result seen early. At the same time, I see the first obstacle and the first bad news not as disasters to be avoided but as opportunities to test and strengthen support. Carrying an obstacle to the executive and having them clear it personally is one of the most effective ways to make that executive the real owner of the project. Executive ownership is cemented not by an abstract commitment but by clearing concrete obstacles together. At the end of the first ninety days I try to make a clear diagnosis: does this project have real sponsor support, or nominal? If this diagnosis is made early, there is still time to change course — to strengthen support, change the sponsor, or narrow the scope. If it is made late, the project may already have entered the path of a project fade-out. I recommend reading this first-ninety-days discipline together with the frame I discuss in from PoC to production AI projects, alongside the general dynamic of the pilot-to-production transition. ## Budget Erosion: The Silent Anatomy of Resource Withdrawal One of the most concrete and common forms of weakening sponsor support is budget erosion. But here is what I saw in the field: a budget is rarely cut with a single decision. Instead it erodes inch by inch; each step looks small and reasonable, but their sum condemns the project to starvation. Understanding the anatomy of this silent resource withdrawal is the precondition for noticing it early and intervening. The erosion usually proceeds like this. First a part of the budget is frozen under the name of "flexibility": "Let us hold this item for now, we will look again at quarter-end." Then someone from the team is shifted "temporarily" to another fire and never returns; this is the non-monetary but perhaps heaviest form of resource withdrawal, because it also takes away the project's accumulated knowledge. Then new spending requests increasingly demand justification; the approval process lengthens, and the question "is it really necessary" appears for each item. In the final stage the budget is not formally cut but becomes effectively unusable — the money exists on paper, but every attempt to use it meets resistance. The root cause beneath this erosion is almost always the same: the project's value has not yet been proven in the executive's language. An executive defends the budget when they see the project produces a concrete business result; when they cannot see it, the budget becomes the first item to cut. So the strongest defense against budget erosion is not an accounting argument but an early, measurable value indicator. Teams that managed to tie value to a business metric preserved their budgets; teams that relied on the elegance of technology surrendered to erosion. The most dangerous feature of budget erosion is that each of its steps looks reasonable on its own. 'Holding an item,' 'temporarily shifting a person,' 'deferring an approval' — none of these raises an alarm alone. But when these small steps come together, the project effectively stops. So watch the budget not item by item but as a trend: in the last three months, how many items were frozen, how many people withdrawn, how much did approval time lengthen? If the trend is downward, then regardless of words, sponsor support is eroding. To build and defend the budget in an executive's language, enterprise AI budget planning, and to show value with numbers, AI ROI measurement, put the observations of this field note into an applicable frame. ## Resistance and Political Ground: The Invisible Rivals of Support A sponsor's support never lives in a vacuum; it always stands within an organizational ground, interests, and politics. An important truth I learned in the field is this: even the strongest executive's support may not suffice if there is an invisible resistance opposite it. This resistance rarely comes as an open "no"; most often it works insidiously in the guise of a passive slowdown, a "but let us handle this first," or a "let us take a look too." The sources of this resistance are varied. Some departments fear the project changing their way of working or reducing their own importance; this fear is not voiced openly but slows cooperation. Some executives are uneasy about their own projects being overshadowed and push your project into the background in the resource competition. Others adopt a "this too shall pass" attitude out of the fatigue created by past failed attempts. Without reading this political ground, even the strongest sponsor support can get stuck in an unexpected place. So building support only with the lead sponsor is not enough; you must detect the resistance points early and factor them in too. The approach I saw work in the field was to invite objections early rather than hide them: asking "what is your concern about this project" early surfaces hidden resistance and often makes it resolvable. An unheard objection returns six months later as a resource withdrawal; a heard objection can turn into a design decision. This was confirmed again and again as a field observation. Another dimension of the political ground is managing the project's visibility. A project announced too early and too loudly creates big expectations and big rivals before producing value; one that stays too quiet cannot accumulate legitimacy and support. The right balance is to stay modest until value is proven, then increase visibility along with the proof. To manage this balance at enterprise scale, enterprise AI strategy, and to design the right role structure, AI organization design, offer a frame. ## Mini Case: Same Technology, Different Fate To make it concrete, I want to describe a recurring pattern I observed in the field — without using fictional names and numbers, through two representative situations. Imagine two projects: two enterprise AI initiatives that are almost identical technically, of similar scope, run with similar teams. One reached production and produced value; the other faded out silently. Seeing that the difference was not technology but sponsor support summarizes the essence of this field note. In the first project, the sponsor had tied the project explicitly to their own annual target. They never cancelled a short weekly meeting, cleared every obstacle personally and quickly, and met the first bad news with a "what did we learn" attitude. The team moved without waiting for decisions; because decisions came within days. When a squeeze arose the sponsor defended the budget and explained the project to senior management in their own words. This project was not perfect, it made mistakes; but the real executive ownership behind it kept it standing through every tremor. In the second project, the sponsor was enthusiastic at the kickoff but became invisible afterward. Meetings were deferred one by one, with people sent in their place; decisions waited for weeks in the approval queue. When the first bad news arrived the sponsor shifted to an "I was never sure anyway" tone and the team was left alone. Resource withdrawal began: someone from the team was shifted to other work, the budget was pushed to "next quarter." No one formally cancelled the project; but six months later it was on no one's agenda. A classic project fade-out. The lesson of these two representative situations is clear and repeated in the same way many times in the field: technology was not the variable that distinguished the two projects. What distinguished them was whether the sponsor support behind them was real or nominal. Same engine, different fuel; same code, different fate. So the first question I ask when starting a project is no longer "which model will we use" but "who owns this work and how real is it." Reading the reflection of this pattern on the adoption side together with the field note on user adoption completes the picture. ## What to Measure and Report to the Executive: A Support Dashboard A concrete way to preserve sponsor support is to choose consciously what you report to the executive. A mistake I saw in the field was showering the executive with technical metrics: model accuracy, latency, token count. These metrics are valuable for the team but meaningless for the executive; they neither feed nor preserve their support. What is reported to the executive must be a narrative of value and progress in their language. The right reporting is a silent lever that feeds support. When reporting to an executive I try to answer three questions. First: "What did this project add to your goal?" — that is, a concrete business result (time shortened, errors reduced, capacity increased). Second: "What did we learn and what is the next step?" — clarity of progress and direction. Third: "What obstacle exists and what is needed from you?" — a concrete request the executive can personally clear. These three questions make the executive a partner, not a spectator; each report turns into an opportunity to re-earn their support. In reporting, honesty is more valuable than allure. Softening or hiding bad news relieves in the short term but destroys trust in the long term. The teams that best preserved their support in the field were those that made being the first to announce bad news a habit; because executives who hate surprises are grateful for early and honest warning. The purpose of a report is not to impress the executive but to inform them correctly and let them make the right decision quickly. This distinction directly affects decision speed. A report going to an executive need not be complex; most often three lines are enough. One: the concrete business result produced recently. Two: the next clear step and expected result. Three: the single decision or obstacle needed from you. These three lines let the executive understand the project at a glance, see its value, and decide quickly. Long and technical reports go unread; short and business-focused reports feed support. To turn this reporting discipline into a presentation and persuasion system, presenting an AI project to senior management, and to build a board-level narrative, the AI investment board presentation, tie this field observation to an applicable template. ## Support Dynamics in Regulated Sectors and Large Organizations The dynamic of sponsor support varies with the organization's size and sector; I want to share this too as a field observation. In small and mid-sized organizations support is often concentrated in a single strong person: the one who decides, allocates resources, and clears blockers is the same executive. This provides a speed advantage but creates fragility; if that person leaves, the project is defenseless. In large organizations, by contrast, support is distributed: the decision passes through several committees, resources come from more than one budget, and a single sponsor's weight may not suffice. The most important difference I saw in large organizations is that support is not a single-person but a coalition affair. Even a single strong sponsor cannot carry the project alone if there are several unconvinced stakeholders opposite them. So in large organizations, support is less about convincing one person than about building a coalition: aligning the interests of different departments, hearing objections early, and making the project the shared goal of more than one executive. This is slower but more durable. In regulated sectors (banking, insurance, healthcare) an extra layer comes into play: support must come not only from the business side but also from the compliance and risk side. In these sectors an executive's enthusiasm alone does not suffice; the legal, compliance, and risk functions must also own the project or at least not block it. I saw in the field that in regulated sectors the fastest-dying projects were those with a strong business sponsor but an unconvinced compliance side. I shared a more detailed observation on the approval dynamic in regulated sectors in the field note on regulated-sector approval. These differences show there is no single universal recipe. In a small organization you must win a strong individual, in a large one build a coalition, in a regulated sector align compliance early. But the unchanging core in all three is the same: a project does not proceed without a real ownership behind it that cares about it and allocates resources. I addressed the frame for how to institutionalize this ownership at enterprise scale in setting up an AI center of excellence. ## The Invisible Link Between Support and User Adoption A connection I noticed in the field and did not expect at first is between sponsor support and user adoption. At first glance these seem separate topics: support concerns senior management, adoption the end user. But my observations showed the two are tightly linked. An executive's visible and continuous ownership makes users take the project seriously too; the weakening of support turns, in the field, into a "this too shall pass" attitude and adoption collapses. Why does this happen? Because corporate behavior reads signals from above. When an executive ties a project to their own goal, gives their own time, and regularly asks "how is it going," the lower levels feel this attention and give the project energy. Conversely, when the executive becomes invisible, users get a silent message: "This work is not a priority, you can continue with the old method." So a technically perfect tool becomes worthless because no one uses it. What kills adoption is often not the tool's quality but the visibility of the support behind it. This link offers a practitioner an important lever. One of the most effective ways to increase user adoption is to use the executive's visible ownership as an adoption tool: the sponsor explaining the project to the teams in their own words, appreciating the first users, and keeping usage on their own agenda is a stronger adoption signal than any training campaign. I saw in the field that the fastest-adopted projects were not those with the best interface but those the executive stood behind most visibly. I deepened this field observation, with the details of the adoption side, in the field note on user adoption. The reverse is also true: strong adoption feeds sponsor support. When users own the tool and see concrete benefit, that benefit returns to the executive and reinforces their support. So a virtuous cycle forms: support feeds adoption, adoption feeds value, and value feeds support again. To start this cycle an early and visible win is essential; this is exactly why an early win is a spark that mobilizes not only the executive but the entire user base. I addressed the skill infrastructure needed to sustain this cycle at enterprise scale in the enterprise AI academy. ## Guiding the Sponsor: Managing the Executive's Expectations The most delicate skill I learned as a practitioner is not managing the sponsor — that sounds manipulative — but honestly guiding the sponsor's expectations. One of the most common causes of support loss I saw in the field was mismanaged expectation. If the executive expects an unrealistic speed or result from AI, then even if the project goes well technically, in their eyes it is "not fast enough" or "did not deliver what was promised," and support erodes. Expectation management is an invisible but decisive part of preserving sponsor support. Expectation management starts at the very beginning. Making exaggerated promises when selling the project eases support in the short term but is a trap in the long term; because every unmet exaggeration hollows out the support. The discipline I learned in the field was to be modest and honest from the start: to say clearly what is possible, what is uncertain, and what will take time. An executive accumulates trust when a realistic promise is made and kept; when an exaggerated promise is made and broken, trust collapses under the weight of the unmet expectation. Another dimension of expectation management is honestly explaining AI's limits to the executive. Many executives, influenced by exaggerated media narratives, think of AI as a magic solution; yet real projects are incremental, experimental, and at times take a step back. Conveying this reality to the executive early and honestly prevents later disappointments from the start. In the field the most durable sponsor support came from executives who understood both AI's power and its limits; the most fragile support came from executives who thought AI was magic. When conveying this reality to the executive, what is an AI roadmap offers a helpful language that frames corporate expectations. Finally, expectation management helps most in the bad-news moment. A practitioner who set expectations honestly from the start can say, when bad news arrives, "we foresaw this together, it was in our plan"; a practitioner who set expectations with exaggeration is forced to present the bad news as a betrayal. Honest expectation turns bad news from a crisis into a learning step. This is one of the strongest buffers that keeps sponsor support standing in hard moments, and it was confirmed again and again as a field observation. ## Institutionalizing Support: From Person to System Perhaps the most important advanced lesson of this field note is this: sponsor support is fragile as long as it depends on the goodwill of a single person; real durability comes from moving support from person to system. The most mature organizations I saw in the field tied the support of AI projects not to a single executive's enthusiasm but to an organizational structure. So when an executive left or their priority changed, the project did not collapse. The first step in institutionalizing support is to build a steering structure instead of a single sponsor. A steering group of a lead sponsor plus a few stakeholders both legitimizes decisions and distributes the single-person risk. When this group meets regularly, decisions about the project are tied not to one person's calendar but to an organizational rhythm. The most durable projects I saw in the field were those that diversified support this way; the most fragile were those that loaded all the weight onto one executive's shoulders. The strongest way to reduce the risk of resource withdrawal is to make the resource no longer dependent on a single decision-maker. The second step is to tie support to a process. When a structure is built in which AI projects are managed as a portfolio, regularly reviewed, and tied to corporate goals, the support of individual projects moves beyond personal relationships. If a project is seen as part of the organization's AI strategy, then what defends it is not a single person but a corporate priority system. I addressed the frame for building this structure in setting up an AI center of excellence and the general strategy ground in how to build an enterprise AI strategy. The third step is to clarify ownership and roles. Institutionalized support gives permanent and written answers to "who owns this project, who decides, who allocates resources." This clarity ensures continuity even when the sponsor changes; because ownership is tied not to a person but to a role. The truth I saw in the field is this: person-based support is fast but fragile, system-based support is slow but durable. Mature organizations balance the two — a strong personal sponsor on one side, a corporate structure carrying them on the other. To build the right role and ownership structure, AI organization design, and the field notes that stand together, the field note on transformation patterns and the field note on projects stuck in the pilot, make this institutionalization concrete. ## Managing the Bad-News Moment: Support's Litmus Test The moment that most clearly shows whether an executive's sponsor support is real is not the first victory but the first bad news. So managing the bad-news moment well is one of a practitioner's most critical skills; because this moment either solidifies support or collapses it. In the field I saw many times that the same bad news, when managed well, strengthened support, and when managed poorly, ended the project. The difference was not in the news itself but in how it was carried. The first principle is to give bad news early. Teams often defer bad news in the hope of "maybe we will fix it"; when the problem grows and erupts, the executive faces both the bad result and the concealment, and loses trust twofold. Early-given bad news, by contrast, offers a chance to intervene while it is still small and sends the executive a "I am trusted" message. The teams that best preserved their support in the field had turned being the first to announce bad news into a discipline; executives who hate surprises are grateful for early warning. This directly feeds decision speed too: a problem heard early is solved early. The second principle is to carry bad news together with a proposed solution. The sentence "this problem arose" leaves the executive helpless; the sentence "this problem arose, we have two options, I propose this and I need this decision from you" empowers the executive. Presenting bad news not as a pile of problems but as a decision point directs the executive to action rather than panic. The most mature practitioners I saw in the field never carried bad news bare; they always brought it with a diagnosis, an option, and a recommendation. This was the strongest moment for making the executive a partner in the project. The third principle is to place bad news in a learning frame. Enterprise AI projects are experimental and incremental; every failure produces knowledge. Framing bad news as "we learned this and are correcting our direction thus" instead of "we failed" lets the executive internalize this experimental nature too. A practitioner who set expectations honestly from the start can use this frame easily; because the executive already knows the road will not be straight. So expectation management and bad-news management feed each other; without one the other is incomplete. A counterintuitive truth confirmed many times in the field: well-managed bad news does not weaken sponsor support, it strengthens it. Because an executive truly trusting the team happens not in the moments when things go well but by seeing how the team behaves when a problem arises. Bad news carried early, honestly, and with a proposed solution proves the team's maturity and deepens the executive's trust. The strongest support relationships I saw in the field were built not on projects that had no bad news but on projects that faced bad news together and maturely. Managing the bad-news moment is also the most concrete proof that support must be built on honesty. An attractive but exaggerated narrative collapses at the first bad news; an honest and modest narrative can carry the bad news. So as a practitioner I chose to build sponsor support not with short-term impressive presentations but with a long-term honest relationship. This relationship was the ground that kept the project standing at the first bad news — the moment projects most often die. I also shared this experience pattern, together with topics that look technical but actually require ownership like documentation preparation, in the field note on documentation preparation and with in-house realities in the field note on on-premise realities. ## The Lessons I Drew from This Field Note If I must reduce all these observations to a few lessons, here is what I have distilled over the years. Read them not as a checklist but as a summary of experience; each earned its place here because it gave the same result across more than one project. First lesson: support is not a signature but a relationship. The initial approval is the start of the journey, not its end. Sponsor support dries up if not continuously nourished; even the best-starting projects fade out when the relationship is neglected. Second lesson: look at behavior, not words. To measure an executive's support, look not at what they say but at how they use their time, their resources, and their risk. The calendar, the budget, and the bad-news moment are far more honest than words. Third lesson: decision speed is support's pulse. If decisions are speeding up, support is strong; if decisions are slowing, support is eroding. Watching decision speed is the most practical way to watch support. Fourth lesson: read the signals early. A project fade-out is not sudden but slow; meeting cancellations, delegation, changing questions, and a deferred budget are early warnings. If you notice early you can save it. Fifth lesson: diversify support. A project tied to a single sponsor is fragile; spreading support to a steering group both legitimizes the decision and distributes the single-person risk. Sixth lesson — and perhaps the hardest: sometimes the right decision is to stop. Forcing an unsupported project drains the team's energy and the organization's trust; an honorable pause is often more valuable than a stubborn drag. Seventh lesson: honesty is the foundation of support. Short-term impressive presentations win support quickly but collapse at the first bad news; a long-term honest relationship can face the hard part. Carrying bad news early and with a proposed solution, setting expectations realistically from the start, and showing value without exaggeration — these are a practitioner's most durable investments in support. The eighth and final lesson is this: support is not something won but something continuously re-won. Every executive meeting, every early win, every honest piece of bad news is an opportunity to renew support. Teams that lost this rhythm lost their support too; those that kept it held their projects standing even under the hardest conditions. Finally, the lesson that stands above all: enterprise AI is not a technology project but a change project; and change is possible only if there is real ownership behind it. Sponsor support is the name of that ownership. Code is written, models are trained, systems are built — but none of these turns into production without an executive who cares about the project and puts their own weight behind keeping it alive. This is the truth I saw again and again in the field, and it is the essence of this field note. I recommend reading this field note together with the field notes home that gathers my field observations, and with my neighboring experience pieces, the field note on the lack of data governance and the field note on integration delays; all describe different faces of the same truth. You can find the broader frame of why enterprise AI investments fail to turn into value in why enterprise AI ROI fails. ## Frequently Asked Questions ### Does a project really have executive support, and how can you tell? The most reliable sign is not words but the commitment of resources and time. An executive with genuine sponsor support gives the project regular time from their own calendar, reorders their own team's priorities around it, personally clears blockers, and ties the project to their own performance targets. In nominal support, by contrast, the executive appears only at the kickoff, constantly defers decisions, and writes the project off at the first budget squeeze. To gauge an executive's support I look at three things: how many hours they gave the project in the last month, how many blockers they cleared themselves, and how many times they defended the project to senior management in their own words. If these three are empty, the support on paper is not real. ### What happens to a project if sponsor support weakens? Usually there is no sudden cancellation; a silent project fade-out begins. First priority erodes; the project slides onto the "important but not urgent" shelf. Then resource withdrawal comes; people on the team are shifted to other work, the budget is pushed to "next quarter." Then the decision queue lengthens; items awaiting approval pile up, decision speed drops, motivation breaks. These three feed each other and the project effectively stops without being formally closed. The most dangerous part is that the process is slow and no one says "we killed the project." That is why reading the early signals of weakening support is the only way to save a project. ### How is executive support strengthened? Three things work. First, speaking business outcomes rather than technology: instead of explaining a model or architecture to the executive, showing how the project touches their own targets (cost, speed, customer satisfaction, risk). Second, producing early and small wins: instead of a big result months away, a concrete, visible improvement within a few weeks renews the executive's support. Third, making the executive a partner: taking decisions together with them, reporting progress honestly, and giving bad news early too. The teams that best preserved their support were not those that wrote the best code but those that talked to the executive most honestly and most often. ### Should you start an AI project without executive support? For a small exploration or proof of concept you can start in a limited way; but a project aiming for production should not be launched without solid sponsor support. The reason is simple: enterprise AI projects are as organizational as they are technical; process change, budget, cross-team coordination, and priority conflicts are resolved only with the ownership of an authorized executive. A project that starts without support, however technically good, gets stuck at the first organizational obstacle. Before starting you should get a clear answer to "who owns this work and why do they care"; if the answer is vague, it is right to build the support first. ### What do you do if the sponsor disappears or changes? Executive change is a fact of corporate life, and a good project should not remain dependent on a single person. The first precaution is to spread support from the start not to a single sponsor but to a steering group, so the project does not collapse when one person leaves. When the sponsor changes, what must be done is to re-explain the project to the new executive from scratch and in their language, gain trust by showing a quick win, and clearly tie how the project serves their targets. Assuming the old sponsor's support will transfer automatically is one of the most expensive mistakes; a new sponsor's support is re-earned, not inherited. ## In Short: Why Is Executive Support Decisive? In short: sponsor support is the continuous, active ownership an authorized executive provides to an enterprise AI project; and most technically sound projects die not from code but from this support remaining in name only. What separates real support from nominal support is the commitment of resources and time; support's pulse is decision speed; and support's collapse is not sudden but a silent project fade-out that comes through priority erosion, resource withdrawal, and slowing decisions. The most important message of this field note is this: enterprise AI is not a technology affair but a change affair; and change proceeds only if there is real executive ownership behind it. Winning support happens not by explaining technology but by speaking business outcomes, producing early wins, making the executive a partner, and reading the signals of weakening support early. I share this not as a theory but as a field observation that gave the same result again and again. To set up an AI project in your organization with the right ownership, find the right sponsor, and make support sustainable, you can start through an AI consulting conversation, review corporate training options so your teams can speak this language, and deepen all the concepts in the learning center.