As outsourcing deals increasingly focus on transformational change, we see IT organizations frequently shifting to the Plan-Build-Run (PBR) model, for a variety of reasons.
PBR separates IT into three separate units – one each for planning, new development and ongoing maintenance and management. In general the ‘planning’ function comprises IT strategy and planning, enterprise architecture, demand management and financial management. The planning unit also functions as a conduit between business and IT, providing consulting services to both, and translating strategic priorities to an IT roadmap. The ‘build’ unit focuses on projects, and spans both new development and project and program management. ‘Run,’ obviously, is the maintenance-focused unit.
Traditionally, IT was organized by tools and technologies – into applications, infrastructure and the project management office, all rolling to the chief information officer (CIO). The PBR model, meanwhile, categorizes IT by work stream, so the applications function is separated into distinct ‘build’ and ‘run’ units, and infrastructure into projects and ongoing asset management and service desk management. As such, PBR represents a significant departure from the status quo.
Despite the inherently risky nature of organizational redesign, the current appetite for PBR is fairly high, and is driven at least partly by IT’s inability to address development needs of the business. More than ever, building reliable and innovative applications on time is a critical success factor in business, and enterprises are willing to consider new organizational structures to expand the development pipeline. In addition, we’ve seen a parallel focus on costs since the last recession, and PBR has the potential to both improve the application development function as well as reduce costs.
By separating development and maintenance, PBR opens up numerous sources of efficiencies. For example, handling sourcing independently allows extensive multi-sourcing for new projects, with considerations of quality, speed and access to specialist skills guiding sourcing decisions. Similarly, considerations of scale and costs can guide sourcing in the ‘run’ organization, as service providers can be consolidated. As another example, proximity is more important in development, and therefore ‘build’ can prioritize onshore capabilities, and run can thrive offshore. Also, if a multisourced environment has a preeminent strategic service provider, that vendor can be inducted into the ‘plan’ function.
The PBR framework also aligns the IT budgeting process with corporate budgeting practices by separating capital and operational budgets.
In ISG’s experience, PBR offers a useful framework for a multitude of transformational IT projects, including a change in the sourcing model, application portfolio rationalization and post-merger integration. Placing existing and future units into ‘plan’, ‘build’ and ‘run’ helps visualize the future state, the interfaces and the flow of work and decisions across various units and teams. We expect the PRB framework to be central to a growing number of discussions around transformational IT projects.