Enterprise, DevOps

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


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.

Laura Wilson is a research analyst for CEB CIO Leadership Council. CEB is a best practice insight and technology company. Read more CEB blogs here.

Sponsored by CEB, now Gartner

Leaders at more than 10,000 organizations worldwide rely on CEB services to harness their untapped potential and grow. Now offered by Gartner, CEB best practices and technology solutions equip customers with the intelligence to effectively manage talent, customers, and operations. More at www.gartner.com/ceb.