Run Grow Transform Model: Portfolio Mix Template

The run grow transform model is a way of splitting a project or technology portfolio into three investment categories: run, the work that keeps existing services operating; grow, the work that improves the business you already have; and transform, the work that goes after a new business model, market, or capability. Gartner popularized it in the mid 2000s as a way for CIOs, CFOs, and boards to talk about spending in terms of risk and return rather than line items.

That is the only definition on this page. The rest is how to use it: a classification template you can copy, the tie-breaker rules that stop the annual argument, how to measure your real mix, what the widely quoted target percentages are actually worth, and how to tell whether the model is changing any decisions or just decorating a slide.

Why the run number grows every year unless somebody stops it

Run spending has a ratchet built into it. Every project that succeeds adds something that has to be supported forever: a new integration, another license tier, one more system in the patching queue, a service with an availability commitment attached. Nobody approves that cost, because it arrives as the tail of a decision that was approved for a different reason. The business case said the project would increase revenue. It did. It also added ninety thousand dollars a year of run cost that appears in next year's baseline as though it had always been there.

Meanwhile the transform work is the easiest thing in the portfolio to defer. It has the longest payback, the weakest evidence, and the fewest people demanding it this quarter. When budgets tighten, transform is cut first because cutting it causes no visible pain for eighteen months. Do that three years running and the portfolio arrives at eighty percent run without a single meeting where anyone decided to stop investing in the future.

This is the actual value of the model. It is not a taxonomy exercise. It gives a name to a drift that otherwise has no name, and it makes the drift visible on one line of one slide, which is the only way it ever gets discussed at the level where it could be reversed.

The run grow transform model template

Three categories, defined by what the money buys rather than by which department spends it. The test in the third column is the one to use in practice, because it can be answered in a sentence by the person requesting the work.

Swipe to see more →

Two design notes are worth defending when someone proposes a fourth category. First, resist adding one. Portfolios that split transform into transform and innovate, or add a compliance bucket next to run, almost always do it to move an awkward project out of a category where it looked expensive. Once four categories exist, the mix stops being comparable to last year's, which was the entire point of measuring it. Second, mandatory compliance work belongs in run even though it feels like a project. It is not optional, it does not grow anything, and putting it in grow makes the grow number look healthier than the portfolio actually is.

Classifying a project when it could go in two buckets

Most of the classification is obvious and takes about four seconds per project. The value is in the ten percent that are genuinely ambiguous, and the way to handle those is to decide the rules once, in writing, before you are looking at a specific project that someone wants funded.

Swipe to see more →

The tie-breaker that resolves nearly everything else: classify by the outcome the organization is buying, not by the team doing the work or the technology involved. A data platform is not automatically transform. A project run by the innovation team is not automatically transform. If the outcome is that an existing process gets cheaper, it is grow, whoever builds it.

One more rule that saves a great deal of time. Do not allow percentage splits across categories at the individual project level except in the genuine hybrid case in row two above. If half your portfolio is recorded as sixty percent grow and forty percent run, nobody can audit it, the numbers become negotiable, and the mix will drift toward whatever makes this year's slide look best. Single category per project, with a documented exception process, is more honest and far easier to defend. This is the same discipline that keeps project prioritization criteria from being quietly re-weighted to produce a preferred answer.

Measure your current mix before you argue about the target

Every conversation about the target ratio is wasted until you know your actual one, and the actual one is almost always worse than the room assumes. When executives are asked to estimate their own run share before it is measured, the estimate tends to come in well below the measured figure, because run costs sit in operating budgets, renewals, and headcount that nobody thinks of as portfolio spend.

A defensible measurement takes about a week and goes like this:

1. Fix the boundary. Decide whether you are measuring the project portfolio only, or total technology spend including operations and headcount. Both are valid. Mixing them is not, and mixing them is the most common reason two people quote different numbers in the same meeting.
2. Pull every cost line, not just approved projects. Hosting, licenses and renewals, support contracts, and the loaded cost of the people who keep services running. Portfolios that count only the project list report run shares that are wrong by thirty points or more.
3. Classify with the table above, one category per line. Get a second person to classify a ten percent sample independently. If the two of you disagree on more than one line in ten, your rules are not written clearly enough yet.
4. Separate committed from discretionary. Multi year contracts and depreciation already signed are not available to reallocate next year, and presenting them as though they were makes the target look achievable when it is not.
5. Publish the baseline before proposing a target. Once a target exists, everyone's classification quietly starts serving the target.

If a large share of your run cost turns out to be cloud, software subscriptions, and renewals that nobody has reviewed in two years, that is worth its own exercise before any reallocation debate, because it is usually the cheapest money in the building. The same goes for the mandatory band inside run: security patching, access reviews, and the control evidence a SOC 2 or ISO 27001 audit expects are genuinely non negotiable, but the effort they consume is frequently three times what it needs to be because it is collected by hand every cycle.

Run grow transform percentages: what the quoted benchmarks are actually worth

Search for a target ratio and you will find several confident numbers. It is worth being precise about where they come from, because most of them trace back to summaries of paid analyst research written by people who were selling something adjacent to it.

Swipe to see more →

None of these are published constants you can cite in a board paper without qualification, and none of them know anything about your business. The number that actually matters is the direction of travel in your own portfolio, measured the same way two years running. A portfolio moving from 74 percent run to 70 percent is doing something real. A portfolio that hit exactly 50 percent because the classification rules were adjusted in November has achieved nothing.

Choosing a target mix your finance team will accept

Set the target from strategy and constraints, in this order. First, what does run genuinely cost at an acceptable level of risk? That is a floor, not a preference, and it should be calculated rather than negotiated down. A run budget squeezed below its floor does not disappear, it reappears eighteen months later as emergency remediation at a much worse price.

Second, what is the organization actually trying to do over three years? A company defending a profitable position in a slow moving market can sit at a high run share for years and be entirely rational. A company whose core market is being reshaped and that is still at eighty percent run is describing its future accurately without meaning to. This is where the mix connects to strategic alignment, and where the target stops being a benchmarking exercise.

Third, what can you actually change next year? Committed contracts, notice periods, and people already assigned mean that most portfolios can move the mix by three to five points a year without breaking something. Announcing a fifteen point shift in one budget cycle is how organizations end up cancelling the transform work in March to pay for an unplanned upgrade.

Write the target as a range with a direction rather than a single number, review it annually, and put it in the same document as the funding decision so the two cannot drift apart. A target that lives in a strategy deck and not in the portfolio governance process is decoration.

The only three levers that move the mix

There are exactly three, and only one of them is comfortable.

Reduce run cost. Decommission systems, consolidate duplicate applications, renegotiate or drop renewals, automate the manual parts of operations. This is the lever that creates room without needing new money, and it is the one most portfolios underuse because decommissioning has an owner who loses something and no owner who gains. Deciding what to retire is the job of application portfolio management, which is why that discipline and this model are usually run by the same people.

Ring fence transform. Fund it as a protected allocation decided before the annual scramble, not as whatever survives it. Unprotected transform budgets are reallocated to urgent run work every single time, because the urgent work is genuinely urgent and the transform work is genuinely deferrable. If it can be raided, it will be.

Grow the total. The comfortable lever, available less often than people hope, and the one that hides the problem: a portfolio whose run share falls only because the denominator grew has not become more efficient, and the ratio will snap back the moment the budget flattens.

Sequence matters. Attempting to protect transform before reducing run produces a protected allocation that gets raided anyway, plus a credibility cost that makes the next attempt harder.

RGT drift rate: the number that tells you the model is working

The mix itself is a snapshot, and snapshots are easy to manage toward. The more revealing figure is how much the mix moved between two consecutive reviews, and how much of that movement anybody chose.

RGT drift rate is the change in percentage points of the run share between one annual review and the next, split into planned and unplanned. Planned drift is movement you decided on and budgeted for. Unplanned drift is everything else: the run tail of last year's successful projects, renewals that rose above inflation, and transform work quietly cancelled during the year.

Swipe to see more →

These bands are an operating rule to calibrate against your own history rather than a published industry constant. Measure your own drift for two cycles and the thresholds that matter for your organization will be obvious. The reason to track drift rather than the mix is that drift is the thing you can actually attribute to a cause, which makes it the thing you can argue about productively in a portfolio review meeting.

A worked example: a 42 project portfolio

A mid sized insurer with 42 funded initiatives and a 21 million dollar annual technology spend, measured on total spend rather than projects only.

Swipe to see more →

Two things stand out, and neither is the headline 70 percent. First, grow holds 24 of the 42 projects but only 21 percent of the money, which means the grow bucket is a long list of small requests rather than a strategy. That is a prioritization problem inside a category, and it is the kind of thing portfolio prioritization exists to fix. Second, the two end of life upgrades sitting in run are worth 2.6 million dollars between them, and one of them is the specific technical blocker to the underwriting data platform. Sequencing that upgrade with the transform initiative rather than as unrelated maintenance is the single highest value decision available in this portfolio, and the category view is what makes it visible.

The insurer's decision was not to chase a 50 percent run target. It was to hold run flat in dollar terms for two years while the total grew, retire four applications, and protect the transform allocation at 10 percent. That produces roughly 62 percent run by year three without a single heroic reallocation.

Where run grow transform fits against prioritization

The most common way this model goes wrong is using it as a scoring system. It is not one. It decides how much money each category gets. Something else decides which projects win inside a category.

Swipe to see more →

Run the categories first and the scoring second. A single ranked list across all three categories will always fund grow work ahead of transform work, because grow projects have better evidence, shorter payback, and louder sponsors. That is not a flaw in the scoring model. It is what happens when incomparable things are compared, and the category allocation exists precisely to stop it.

Five ways the run grow transform model fails

It becomes a labeling exercise. Every project gets a tag, the pie chart appears in the annual deck, and no funding decision is ever made differently. If the mix has never caused a project to be deferred or a system to be retired, the model is costing you effort and returning a slide.

The categories get redefined when the number looks bad. The fastest way to improve your mix is to reclassify, and it is always available. Lock the rules in writing, keep last year's classification visible next to this year's, and require a named approver for any project that changes category.

Run is measured on projects only. This produces a flattering number that falls apart the moment finance looks at total spend, and it destroys the credibility of the whole exercise in one meeting.

Transform is used as a status symbol. When transform is the category executives want their work in, everything becomes transform. The check is simple: if a transform project's benefits case reads like an efficiency saving, it belongs in grow.

Nobody owns the run tail. The single most effective fix is also the least glamorous. Require every business case to state the annual run cost the project will add, name the budget that will carry it, and report against that estimate a year later. Portfolios that do this see the run share stabilize within two cycles, because the cost stops being invisible at the moment it is created.

Frequently asked questions

What is the run grow transform model?

The run grow transform model splits technology and project investment into three categories: run, which keeps existing services operating; grow, which improves the current business; and transform, which builds something the organization cannot do today. Gartner popularized it in the mid 2000s. It is used to set how budget is allocated across the three categories before individual projects are ranked.

What is a good run grow transform ratio?

There is no universally correct ratio. Commonly quoted figures include roughly 70 run, 19 grow, 11 transform as a typical current state, and around 50, 25, 25 as an aspiration, but these come from secondary summaries of paid analyst research and are not situational. The right target depends on your run cost floor, your strategy over three years, and what your committed contracts allow you to change.

What is the difference between grow and transform?

Grow makes the business you already have bigger or more efficient within the current business model. Transform creates something that does not exist yet: a new market, revenue model, or capability. The practical test is whether success changes what the organization is able to sell or do. If it only changes how well it does the current thing, it is grow.

Is run grow transform only for IT?

No. It originated in IT spend analysis and is most common there, but the same three categories work for any capital constrained portfolio, including operations, marketing, and research. The categories are defined by the type of return being bought rather than by the department spending the money, so nothing about them is technology specific.

Who decides which category a project belongs to?

The portfolio management function or PMO should apply the published rules, with the sponsor stating the intended outcome and a named approver settling genuine ambiguity. Letting each sponsor self classify guarantees category inflation toward transform. The classification should be reviewed as a set once a year rather than defended project by project.

How often should you review the run grow transform mix?

Set the target annually alongside the budget, and check actual drift quarterly. Annual only is too slow to catch transform work being cancelled mid year, and monthly is more precision than the underlying data supports. The quarterly check should report drift in percentage points and name the cause of any unplanned movement.

What is the difference between run grow transform and the three horizons model?

Three horizons organizes initiatives by when they are expected to pay off, from the current core through emerging opportunities to future options. Run grow transform organizes them by what the spend buys right now. They overlap heavily in practice, but horizons is a time based planning device while run grow transform is a budget allocation device, which is why finance teams generally find the latter easier to work with.

Where this fits

The category mix is one of the inputs to the project portfolio management process, sitting between demand management and the ranking work done with project selection methods. It informs the shape of the portfolio roadmap and gives IT portfolio management its main reporting line. Retirement decisions that free run budget come from application portfolio management, and the deferral cost of postponed transform work is best expressed through cost of delay.

Upward, the mix is reported through the portfolio status report, tracked as one of the PMO KPIs worth keeping, and owned in most large organizations by the enterprise PMO. Organizations running lean portfolio management reach the same allocation decision through funded value streams instead of annual categories. The discipline all of this belongs to is project portfolio management.

Last updated August 2026.