CEB Blogs


Corporate IT

4 Reasons the Plan-Build-Run Model Won't Work Anymore

The plan-build-run operating model is good at implementing long-term plans efficiently, but that's far less attractive for most big companies who are now investing millions in digitization initiatives

Take a perch as the proverbial fly on the wall at any meeting of a big company’s senior executive team and it’s likely that the vast majority will understand why they should make digitization a priority for their firm. They know that intelligent use of data and digital technology will make products better, their sales channels more productive, and their operations more efficient.

In fact 87% of business leaders say that digitization is a priority for their company, according to CEB data, but two-thirds also say that their companies are not acting quickly enough to remain competitive.

This shift across the past five years – where it has become as essential a leadership competency to get the most from technology and information as it is to get the most from your teamhas changed the role of corporate IT professionals. And, to keep pace with digitization, IT must change how it’s run, managed, and structured.

The Start of End-to-End IT Services

To do this, IT teams at big companies are emulating startups and technology firms by shifting their IT operating model towards a product management approach, whereby they offer end-to-end IT services to support a particular product or business process (all sales to premium customers, say).

This kind of operating model gives line managers a better understanding of IT costs, helps IT employees to connect more closely to the business goals they are trying to support, and increases IT’s flexibility and speed. In essence, end-to-end service models aim to help achieve a specific business goal (increase customer satisfaction with the sales process, say) rather than aim to complete a project, where the outcome is to launch a specific piece of technology on time and on budget.

Many IT functions are currently organized around this latter, “technology outcome” type of scenario, and which is typically called a plan-build-run operating model. The aim is to separate business-facing “plan” functions such as business relationship management and business analysis from “build” functions, such as applications development and engineering, with “run” functions (service desk and operations) separated into yet another discrete unit.

The Four Drawbacks of the Plan-Build-Run Model

While this model makes sense for an IT function where long-term planning, efficiency, and standardization are the key concerns, it has four clear drawbacks for an era of digitization.

  1. It is set up to anticipate and plan demand: Plan functions are structured to receive stable and predictable demand from business partners, but business demand for digital projects is neither stable nor predictable. IT needs a model that is not tied to rigid, multi-year plans and can flex and adapt between different engagement models, responding quickly when required but also capable of proactive engagement with business partners to help spot new digitization opportunities.

    In an end-to-end model, service managers work directly with one or two business capabilities, giving them deep insight and understanding into the technologies and the people that support those capabilities. This enables them to be proactive in recommending technologies, and understand when to adapt their engagement posture for different kinds of initiatives or stakeholders.

  2. Decision rights are diffused and confused: Too many people across IT have the ability to stall or stop an initiative, from business relationship managers to project managers, enterprise architects, and IT infrastructure leads. In a digital business, delays caused by handoffs and reviews between these different groups can drastically affect the IT team’s ability to implement their priorities.

    In end-to-end services, only service managers and their business partners have the ability to fully stop an initiative, and the best teams provide different tiers of governance (such as architecture and security reviews), offering lighter-weight options for capabilities where there is low risk but high value to be gleaned from increasing delivery speed.

  3. Build and run are too far removed from business processes: Removing the build and run parts of the IT team from any interaction with the line means that developers and operations staff don’t have as good an understanding of important business processes, and what it is they are ultimately trying to help with. This often makes them slow to respond to changes in business needs, and take longer to understand the needs of the business partners they support.

    In a service management model, IT service managers are supported by business analysts, solution architects, and project managers that are aligned to the same business capability.

  4. The model struggles to adequately support experimental or prototype projects: Plan, build, run is designed for a world where projects are built in-house using mainly Waterfall methodology, and where projects were completed in a linear fashion. Parts of the IT team can struggle to keep pace with iterative project development and the rise of “as-a-service” technologies, which are both key characteristics of digital initiatives.

    The shift in mindset whereby end-to-end service models work with the aim of achieving a specific business goal rather than producing a particular technology solution on time and on budget is incredibly important, as what the line is asking for will change as line managers learn and the business develops. The “test and learn” approach is set up for iterative development and prototyping as a way of achieving those benefits.

More On…

  • Digital Enterprise 2020

    These resources will help you understand the future role of digitization at your firm, and the implications for the corporate IT team.

10 Responses

  • Kevin Johnson says:

    FINALLY someone came to their senses!! I was a PM in a Plan-Build-Run IT group just as they were making this transition. It was awful. They removed the skill set from the seats and re-hired button pushers. And everything in each silo was handled as a Production ticket request to engage their group. No continuity and no consideration for Project work. All FIFO methodology. I always wondered who came up with this methodology and way it became so widespread in large Corporate America?? Anyone in IT can look at this methodology and can tell you 20 reasons why this won’t work? Someone ‘upstairs’ made this decision.

    • Michael Wood says:

      My group supports most administrative systems for a large manufacturing company. We are into our third year of the Plan/Build/Run concept. It is a total mess. Our leadership chose to create a completely separate RUN organization. Both the RUN and BUILD groups are managed, separately, and only meet at the CIO level which, of course, is way too high to understand and deal with the details of two completely different organizations with separate budgets trying to support the exact same applications and business customers at the same time with the same code. It is chaos, but, in today’s uber politically correct world, no one is able to step back and admit it doesn’t work.

      Someone asked why these concepts come around. It is my belief and 35+ years of I.T. experience that such concepts were always out there, coming and going, but common sense and good business decisions based on long-term benefits to the company rejected them. Today, young executives with little, if any, experience in how I.T. really works (usually with some Project Management degree) are focused on only one thing – delivering something new and seemingly exciting – whatever it is. Get the trophy, update the resume and they’re one step closer to CIO somewhere else!

      Our business culture has become so corrupted with personal career over business benefit that we, almost as a general rule, always make the wrong business decisions. I’ve seen it the successful way “back in the day” and I’ve see what is happening in recent years. But, another feature of today’s “five-year plan”-generation is that they absolutely look at experienced, senior employees as brainless and out of touch, so, they have no respect for their observations and advice. This just adds to the near guarantee that bad business decisions will be made and poor concepts and ideas that used to be skipped will end up being embraced and deployed. We find out they were bad ideas just about the time those who “found them on the Internet” and ordered them implemented are having their second interview for that big executive promotion they were looking for at twice the salary at some other company. Meanwhile, the next generation of executive wannabees coming from some indirect career path are zoomed in from some other company and they smile and say, “Here’s a really new and cool thing I’ve seen other companies moving toward – and it really works great! So we’re going to implement it here, too! Any questions?” And the downward spiral continues.

      It amazes me that this young generation of executives shows up one day, takes a cursory look at the operation they have been given charge of and orders implementation of completely new concepts and practices without ever wondering how the company has been successful up to now. Without any thinking they throw out 50+ years of process improvement, experience and success just so they can make a big change with their name on it and all the glory and riches that brings to them. It’s as if they think the existing operation is antiquated and dysfunctional and they are here to bring in their “fresh” new ideas (which the company has told them they want). All the professional, experienced, dedicated and successful people that build the I.T. operation up to that point (if they aren’t sitting at home taking early retirement) must have been misguided or, at best, not very creative or intelligent. I suppose they think the company is here today just by luck or otherwise in spite of the dullards running the I.T. department.

      So, yes, I place the Plan/Build/Run concept into the “bad idea that used to be ignored” category. Can it work better than my company’s version of it? Absolutely. Is it or can it ever be the optimal way to run a large I.T. organization? Nope. Will it ever save the company money? Nope (only on paper). Will it provide the company better leverage and competitive advantage over others? Not a chance. America became the greatest business success story in world history. The most important factors in that happening were that we humbled ourselves to experience and success and, when we were smart enough, we built on that success making it even better. And if an idea didn’t work we were able to admit that and try a different direction. These two critical traits don’t exist anymore and American business is suffering because of it. If it’s new, it must be better and if that bright, young exec we found over at Acme, Inc., likes it, it is absolutely better than anything we’ve done and we will embrace it.

  • Laura,
    You have an interesting point, but I think you are only partially on target. The primary rationale for Plan-Build-Run is commonly mistaken as delivery-focused. Yes, it’s a method to get work done (what isn’t?), but the core impetus for Plan-Build-Run is methodical financial controls. Startups don’t need it because at that phase, expenses are loosely controlled. An end-to-end service would allow a different type of financial control that might fit some organizations, especially if the product/project has a direct relationship to distinct income and expense.

    Kevin’s comment is right on the money when he says it was created “upstairs”. Plan-Build-Run is an asset allocation method. Imagine, as a CEO, I want to deliver more projects in a given year. I can directly add resources only to Build. Or, imagine I believe productivity is being lost due to support issues. I can directly add resources to Run.

    Plan-Build_run is definitely NOT going away. Companies with tight reins on their internal asset allocation will continue to target PBR or other means of finely controlling the interaction between allocation and performance.

    However, companies with other primary foci, for example innovation or growing market share, will (and should) consider other operational designs better suited to their business objectives.

  • Mustafa Ali says:

    I have to say the article is interesting but I would put any failings down to people not understanding how to use a methodology as opposed to adhering to a standard.

    For example, the Plan phase does not mean that organisations must have functions solely dedicated to planning related tasks/activities.

    The Plan,Build Run model is about ensuring organisations can ‘test’ their thinking and ensure that there are no gaps in the design of the new/changed organisation.

  • Todd says:

    Whoever came up with this model never spent a minute supporting IT. Developers need to eat what they kill. Who better to support something but the person who built it and knows it… This may look nice in paper but it the real world it is horribly inefficient.

    • Joe R says:

      You may be reading more into PBR than it asserts. It’s not arguing for silos as much as “who ultimately is responsible for this domain?” Even in bastions of CI/CD like Netflix, you have some degree of specialization. Everybody is “accountable” for “eating their own dog food”, but there are still engineering teams that are “responsible” for focusing on reliability across the entire ecosystem. These are the teams that came up with things like Chaos Kong. Those teams would be “run” teams (not to be confused with “ops teams”).

  • Antony D'Cruz says:

    Interesting point of view but I think its only half the picture. The traditional PBR model does not fit all situations but does still have its place in an organization. When cost efficiency, stability and controls are the main concerns, PBR would work better. I’m not sure I’d want my electric utility, nuclear power plant or hospital ICU taking a rapid fire, ‘Let’s try it and see what happens’ approach to technology implementations.

  • Joe R says:

    The seeds of a healthier alternative to PBR can be found in the work of people like Simon Wardley and Dave Snowden. The problem is the “P”. “Plan” presumes the ability to prepare for something. However, to be able to participate in digital ecosystems, you have to be more nimble. Your ability to plan is limited, and execution with limited data becomes the norm. Rather than “Plan”, you need to “Build->Measure->Learn” with *very* few constraints, in risk astute ways. Once you’ve discovered a digital opportunity, you need to shift gears to begin to manage it in a healthier way (what we traditionally identified with “build”), commensurate with the revenue increase or expense reduction you’re achieving. Finally, when it reaches cash-cow stage, you need to heavily focus on expense reduction to maximize the benefits. Traditionally we think of this as “Run” (as in “Run efficiently”). To some degree these happen simultaneously, but it’s useful to separate them in your head, so that you can thoughtfully govern the transitions.

  • Ripley says:

    Our company was recently required by a slightly larger company. The acquiring group has been working to solidify and adhere to the PBR model for a few years. Meanwhile, the IT organiztion of 50 people (part of the acquired team) is not accustomed to PBR. The PBR model seems to force a disconnect with the business and slow things down. So, does anybody have success stories with PBR?

    I’m not a fan of PBR.


Leave a Reply



Recommended For You

Corporate IT: 3 Keys to Success in Implementing End-to-End IT Services

Big changes in how managers use data and technology has meant equally big changes for...