How to create a new financing model for product-based IT

As technology departments move away from traditional project management frameworks and toward treating IT as a product, it's sparking a broader rethinking of how technology initiatives should be funded.

Under the existing "plan, build, run" model, the business unit would first send a project requirement to IT. The IT team would then estimate the project cost, work with the business unit to agree on a budget, and then start work.

[[317646]]

But this setup has several flaws that hinder agility and cause headaches for everyone involved. Cost estimates often occur before the project scope is truly assessed and understood, and any changes in the plan go through a painstaking change control process. What’s more, funding for these projects is often locked into a fiscal year, regardless of changing business priorities or shifting market dynamics.

To realize the benefits of a product-centric operating model, the funding model must also shift. Instead of funding projects for a specific time based on estimated requirements, teams are funded on an annual basis (also known as "perpetual funding"). This provides IT product teams with stable funding that they can reallocate as the business changes. It also allows teams to spend time reducing technical debt or improving internal processes as they see fit, which can improve productivity and quality in the long run.

“We have to align governance, spending models and priorities,” Intuit CIO Atticus Tysen said during a panel discussion in 2019. “The days of defining a budget at the beginning of the year and then working your way through it and delivering it with a business case are over. That’s outdated.”

Business unit leaders may wonder: Why pay upfront for more services than we need now? A closer look reveals that this model often delivers more value for every dollar spent. For example:

• Permanent funding enables dedicated teams to take end-to-end responsibility for the entire product lifecycle, from launch to end-of-life. This structure can encourage teams to develop more domain knowledge and prioritize reusability and reduction of technical debt, which can also improve technical assets and reap dividends in future iterations.
• Unlike IT where business units “throw business requirements over the wall”, business teams work directly with product teams to jointly develop product roadmaps and validate the value, usability, feasibility, and actionability of ideas before they are prioritized in the backlog.
• Ongoing funding support fosters greater autonomy and empowerment, as cross-functional teams will be able to take responsibility for deciding the best way to invest on behalf of the business.
• Progress is measured against business results achieved, and without a change control process, operations can cease or reallocate funding in perpetuity.

The first step to agility

Changing old financing methods and adapting to new ones may seem like a daunting task, but there are a few steps you can take to get started:

1. Establish a baseline

First, establish a baseline for measuring the effectiveness of the funding shift. A technology leader must consider all aspects of service when making a shift. Two areas of improvement that have a large impact on the business are service quality and price. To establish a baseline for service quality, it is important to measure things like cycle time, defects, net promoter scores, and key business metrics that are heavily impacted by IT solutions.

Price benchmarks are a little harder to determine. The most straightforward approach we have found is to look at projects completed in the last fiscal year and record the resources required to complete them. Start with total compensation for team members (salary plus benefits), add in overhead (hardware/software costs per employee, licenses, etc.) and then communicate in terms of business value delivered. For example, “Project A cost $1.2 million using 6 full-time employees and increased sales associate productivity by 10%”. When phrased this way, your audience will clearly understand what was delivered and at what cost. This clear baseline of cost per business outcome will serve as a useful comparison when you move to permanent funding and need to demonstrate impact.

2. Lead with a proven team

The shift to a new funding model will be visible to all business leaders. To create the greatest chance of success, choose the right teams to attempt this shift. The best candidates for early adoption are high-performing teams that know their role in the product operating model, have strong credibility with business unit stakeholders, and have ongoing demand.

In our work with large organizations piloting this shift, we’ve found that eCommerce teams tend to fit this model better because they have clear business stakeholders and have already developed the skills and relationships needed to succeed in a product-based model. Customer Success teams that have a direct impact on the growth and longevity of recurring revenue streams are also strong candidates because their solutions (like customer portals and knowledge bases) can directly influence how well customers adopt, expand, and renew subscription products.

3. Teach your leaders the basics of team assessment

The product-based funding model is different from estimating in a project model. Under the new model, teams are funded by the business on an annual basis (or another agreed-upon funding cycle). As funding moves to an annual basis, so should cost estimates. Rather than defining a price range for a project and then building a temporary team to execute it (and then disbanding it after execution), leaders should size and price a team to support the expected demand for the year, then guide that team into an ongoing dialogue with the business to continually prioritize target business outcomes.

When completing a team-based cost estimate, it is important to include the same cost elements used to establish a baseline (salaries, benefits, hardware, licenses, etc.) so that the individual cost elements can be compared when demonstrating the ROI of product-based funding. One difference you will see in a team-based model is the resource capacity required to deliver on requirements. In a product model, a cross-functional team will forever work on a single business area and typically will not have any time to acquire the required business and technical knowledge.

And because teams are always working in the field, they are encouraged to view technology assets vertically and are able to quickly identify and use reusable components such as APIs and microservices, which can greatly reduce time to market. For these reasons, teams with perpetual funding in a product-based operating model are able to achieve more business value with less cost.

The pilot team should work closely with the business leadership that provides the funding. Stakeholders should work together to develop a list of quantitative and qualitative business outcomes for the year (or other funding cycle) that also meets any requirements of the existing funding process that operates on a “by-project” basis.

4. Communicate with finance early and often

If you don’t already have a strong relationship with the finance community, start now. Your partnership with finance at the corporate and business unit level is critical to executing your pilot and paving the way for broader enterprise adoption of a team-based funding model. Ideally, leaders should engage with finance before, during, and after the team-based funding model so that everyone is aligned throughout the pilot. This alignment can help spur adoption in other areas of the business, too.

Every finance department has unique processes, culture, and relationship with IT, so while you will need to tailor your approach, here are a few topics you should address:

• The basis for team-based funding. Explain the drivers for team-based funding, the timeline for the pilot, the mechanics of the cost/benefit assessment, and how you plan to demonstrate ROI.
• Business sponsorship. Let finance know you have the support of the appropriate business units. In our experience, this helps a lot in the early stages of the discussion.
• Baseline Assessment. Discuss how you plan to develop a cost/benefit baseline to ensure you are accurately and fully factoring in cost estimates. At the end of the day, you will need finance to give you the nod as you demonstrate the ROI of the pilot and prepare for further adoption.
• Funding process. Define how team-based pilots will fit into existing funding processes. This will help ensure that finance has all the qualitative and quantitative data it needs to support the pilot.
• Spend allocation. Discuss any possible changes to team structures that could impact how Finance attributes spend to specific cost centers.
• Capitalize. If you are currently a waterfall team, communicate that your pilot team will work in an agile manner to maximize the benefits of investing in the pilot. Emphasize the need to identify capitalization candidate criteria within an agile framework.

Evaluating and sustaining success

1. Measure success and demonstrate value

You need to succeed in your pilot to drive adoption in other areas of the business. Your success needs to be communicated in a way that resonates with the business. When your pilot reaches its endpoint, collect your baseline data and match it to the results of the pilot. Put together a “roadshow deck” that shows a side-by-side comparison of costs, resources, and business outcomes (business KPIs, quality metrics, cycle time, net present value, etc.) before and after turning to team funding.

Depending on your organization, it may also be prudent to include other observations, such as the number of change control meetings required under each funding model, metrics on team morale, and other qualitative benefits, such as flexibility. Have conversations with other areas of the business that might also benefit from team-based funding (start with one-on-one meetings), and include partners from finance and product teams as part of the discussion. The most important part of your story is that the team-based funding model delivers more business impact at a lower cost than the old model.

2. Results management

You need to establish a light and flexible governance mechanism to monitor the performance of teams operating in a team-based model. The purpose of these mechanisms is to validate that the increased level of autonomy is leading to high-priority business outcomes, rather than reviewing progress against design specifications or other paper-based milestones. A $40 billion global manufacturing client that has adopted a team-based funding model has established quarterly portfolio reviews with business unit leadership and the CIO to review results. Business leadership is required to review the team’s results and the planned roadmap for the next quarter. Business unit leadership then has the opportunity to reallocate investments based on changing business needs or can advise the team to proceed as planned.

3. Change Management

It is important to note that this process also requires the ongoing involvement of the business units. While funds will be allocated on an annual basis, analysis and demand forecasting will need to be done at least quarterly and funds reallocated accordingly. In the event that investments need to be changed mid-financial year, it is important to note that the growth unit in this model is a new cross-functional team that is able to focus on a targeted set of business outcomes. The idea is to create several high-performing, long-term, cross-functional teams that will have the resources needed to achieve the targeted business outcomes, rather than simply throwing additional contracted developers into the team when new scope is introduced.

Moving from project-based funding to product team-based funding is a significant cultural and operational change that requires patience and a willingness to iterate. If executed successfully, CIOs will develop closer relationships with business partners and be able to deliver higher-quality products more cheaply and more efficiently.