In today’s age of digital disruption, the ability to deliver value quickly is essential for an organization’s survival. This need is among the reasons for the growing popularity of Agile, with its ability to deliver more rapidly and enable more rapid feedback cycles with customers. Agile has come a long way from the days of being a fringe ideology reserved for mavericks and outside-the-box thinkers. These days, top organizations around the world are adopting Agile at scale and moving away from the traditional project funding model.
There’s one aspect of Agile that is talked about a lot these days that relatively few people truly understand––the product model. This approach is used to de-centralize decision making and more closely and consistently align digital resource capacity to the lines of business through which the company delivers value to customers. It’s a move away from the traditional project funding model, by which decision making was centralized via a slow and costly process of estimating all potential work and temporarily allocating shared resources to approved work, toward a more Lean Portfolio Management style of planning, funding, and work delivery.
Before we can properly understand the product model and its benefits, we need to first review the project funding model to understand why it emerged and the challenges it creates.
Problems Associated with the Model
When you describe Agile to people who’ve worked in IT for a long time, it’s not uncommon to hear, “But that’s how we used to work!” They’re not wrong. Before the 1990s, IT departments were much smaller than today because computing was limited to mainframes and other large central devices. The 1990s saw the emergence of PC-based client-server systems, and especially those delivered via a web browser. Suddenly every department in a company could create customer software using relatively simple tools—and they did. You saw servers sprout up everywhere—under desks and in broom closets. It was exciting, but it created some problems.
CFOs noticed all this spending and realized how inefficient it often was. Each department buying their own powerful server to run one system wasn’t the best use of money. All those computers scattered around the office were a security risk—lots of sensitive data that could be stolen or lost if a hard drive failed. And, work was often done inconsistently with each department hiring their own programmers making support and integration a real problem. So, IT was re-centralized. More companies created central IT departments under chief information officers, often reporting to the CFO.
In this model, finance decides each year how much they want to spend on technology given the company’s financial situation and ‘tax’ the business units a portion of their revenue to create a central pool. The executive team sets out strategies that are meant to drive investment decisions. In theory, projects are selected based on these strategies to focus resources on the highest priorities for the company as a whole. In practice, local priorities usually drive the process, with each area working the process to get ‘their’ money back.
Business cases are massaged to generate the pretty picture that will get the nod from finance. Once the work actually starts, almost all focus shifts to holding IT accountable for how well they perform against estimates that are often adjusted in the planning process in order to secure approval. And, the original business value that was promised is rarely evaluated post-project. Success is generally measured via the project management iron triangle of On Time, On Scope, On Budget. Never mind whether the work delivered actually generated real results for the business.
The project model created a number of problems that negatively affected the way teams planned and delivered innovation.
The problems with the project funding model don’t stop there for organizations where people report into functional silos––which is common in IT organizations—and percentages of their time are temporarily allocated to various project teams. This creates an uneasy situation where multiple projects are competing over the same resources, namely the people are assigned to more than one project. And naturally, in this situation, every project manager argues their project is the most important for the company.
As you can imagine, this creates a difficult work environment that ends up hurting the company. It means different teams within the same organization are working against each other to achieve their project goals, instead of working to push the company forward. What’s more, this model leaves the organization in a constant state of uncertainty and instability. Because resources are shared (and competed over) across multiple projects, a setback on one initiative will have a domino effect that hurts all the other projects.
Sounds counterproductive, right? It is.
In addition to being unstable and unpredictable, this shared resources model isn’t effective for delivering continuous improvement. People are constantly pulled from their functional departments and assigned to different project teams. Once they complete their purpose within a team, people are removed and allocated to a new group, and the cycle continues. They’re stuck in a transient state, with neither the time nor the incentive to invest energy in continuous improvement. In fact, given the demands of On Time, On Scope, On Budget, the team is positively encouraged not to focus on anything but project success. And there is often a separation between people who implement projects and those who handle operations and maintenance. So, the project teams don’t have to deal with the problems that they cause downstream. Far from encouraging improvement, it’s a recipe for poor quality and technical debt.
In the next part of this series, we’re going to take a look at how these problems are addressed under the product model. In the meantime, learn more about how Planview supports shifting from projects to products by watching the demo or download our whitepaper on “Lean Portfolio Management for the Enterprise” to see how organizations are turning to LPM to help make the shift to a product-centric model.
