If your organization is going through the transition from projects to products for its internal software development efforts, you may ask some variation of this question:
How is product funding /financial tracking supposed to work?
Chances are you spiced up that question with an explicative or two for good measure.
The question is important, and is difficult to answer because it entails regulations, accounting principles, interpretations of those regulations and principles, software development theory, and two groups with different, but not conflicting, goals.
To properly answer this question, I think it’s helpful to explore the different perspectives involved and split the question into three specific parts. With that in mind, here’s how I organized this article:
- Differing, but not competing perspectives (What finance wants, What product teams want)
- Funding products
- Ongoing funding decisions
- Accounting for the use of funds
My intent here is to raise awareness to some issues that you’ll want to work through with your finance area and some ideas on approaches you can take to get the finance folks what they want without putting an undue burden on your product teams.
Differing, but not competing perspectives
To understand the implication on finance and accounting of switching your primary approach to developing internal software from a project approach to a product approach, it’s helpful to know the different perspectives in play.
Project or Product or both?
I won’t delve too much into the project vs product argument here. Chances are if you’re reading this article you’ve already decided you want to head down the product route and are now trying to figure out how to make it happen.
I’m also going to avoid the “projects bad; products good” trope that most articles covering this topic inevitably invoke. Each approach has situations where they are better suited and where they can be detrimental.
To properly set context, here’s a comparison of the project approach and the product approach. I selected the comparison points as the ones most relevant to a tech enabled organization that uses software to enable its business processes.
I sourced this information from Products Over Projects which provides a more thorough explanation of the topic if you’re interested.
| Comparison point | Project approach | Product approach |
| What gets funded | Pre defined solution or scope | A team, usually on a rolling basis with periodic reviews |
| What part of the development lifecycle is funded? | Building and deploying the solution | Building, running, and iterating on the solution (or creating a different solution) until the outcome is reached |
| Who owns discovery, build, and run | Separate teams/departments | A single team/department |
| How are teams organized | People are pulled from impacted departments and form a temporary, often part time, team to deliver a solution | An empowered, business-capability-aligned, long-lived, cross-functional, team asked to solve a problem and improve a business outcome |
| How long do teams last | While project funding lasts, ideally until the solution is delivered (weeks or months) | As long as the outcome has business relevance. (Years) |
| How does prioritization work | Projects are prioritized by business and portfolio management group | Product teams prioritize work to reach their outcome. Business and tech leadership prioritize cross-cutting initiatives. Work for initiatives is parceled out to pre-existing product teams |
| How is value measured | Part of the effort of project approval is estimating projected benefits. There is rarely validation of the actual benefits after the solution is delivered | The product team is asked to reach an outcome along with appropriate metrics that act as leading indicators as to whether the outcome has been achieved. The product team monitors those metrics to guide their product decisions |
| How is success defined | The agreed upon scope is delivered on time and budget | Via the metric described above. These metrics measure things that are in the product team’s control and indicate progress toward reaching a business outcome |
What Finance wants
Here is where I put the disclaimer in that I’m not an accountant or finance professional, so most of the content here is based on research I’ve done from sources that are better situated to speak to these issues. If I’ve missed, or mis-characterized finance’s needs, please let me know.
Finance people want to manage an organization’s finances. In other words, make sure that an organization is making the best use of its limited financial resources.
They want to have clarity about the organization’s investment decisions and whether those investments are producing an appropriate return.
Finance people are happiest when they can tie an investment decision directly to revenue and income. That’s easier to do with products that you sell than products that are one or more steps removed from activity that generates revenue.
Finance people also want to make sure they’re properly accounting for an organizations expenditures. This is both to optimize income and tax liabilities as well as properly adhering to regulations and accounting principles.
They don’t really care how you build and maintain software as long as the activity contributes positively to the business overall and they can properly account for the work involved. This means that they’ll often look for help to translate how software development activities best fit into their picture of how a business operates.
What product teams want
Product teams want to know how much money they have available, and how they can request more if need be. Once they have those funds budgeted they want as few barriers as possible to spending that money. They would prefer to not have to provide estimates tied to delivery of specific output because they know they’ll be wrong.
Product teams also want the flexibility to work in the manner best suited to their situation. They want to avoid processes imposed from outside that have limited apparent value – the prime example being time tracking.
They understand other groups need for information about their work, but they don’t want to step away from their actual work to provide updates about the work. Their preference is that their tools generate the necessary information as they work through their normal processes.
Funding products
Organizations typically use a project approach to determine how to fund activities that drive some change in their operation. A project request usually contains at minimum a defined solution and cost and time estimates for delivering that solution. A portfolio management function compares the various project requests and determines which get funded.
You have to apply the allocated funds to deliver the defined solution unless the project goes through a change control process which is usually not designed to be something that people want to go through.
The funds in effect are tied directly to delivering specific scope items. If any of the scope items involve software, an existing department becomes responsible for administering and maintaining the software and making any further revisions. More often than not the team that “runs” the software differs from the team that “built” the software.
In contrast, tech companies fund product development as an investment. They identify a business outcome they want to reach over the next few years and then decide how much they’re willing to spend (some call this a bet) per year to reach that outcome. That amount relates to the product team that will own that product.
As Brent Swanson describes it, when you invest in a product, you fund a product team “to deliver the maximum value for the lowest estimated effort (risk and uncertainty). “
With products you sell, “value” is the revenue and income that your product generates. With internal products, value is progress toward reaching the business outcome you set out to achieve.
Since you fund your product team for the entire budget cycle, they effectively “own” the product, and are asked to solve a problem rather than deliver a specific solution, you behave differently toward your product.
- You’ll incorporate short feedback cycles to deliver an increment of your solution, collect feedback, and revise your approach. This helps you determine the best way to invest in order to reach the business outcome.
- You’ll allocate time toward reducing technical debt or improving internal processes so that your product is easier to support and you have time to add new functionality when you need to.
- Your product team develops greater domain knowledge so you can increase reusability and reduce technical debt.
- Your product team works directly with business units to validate the value, usability, feasibility and viability of an idea before you implement it.
Governing the use of funds
I suspect some folks used to working in a project approach will read the description of product funding above and exclaim – but how do you make sure the funds are being used properly? You have no control! You’re letting the product team do what they want!
I’m going to resist the temptation to ask people that react like that how often they’d go back and measure the revenue increases or cost savings their projects promised when approved.
When you follow the product funding model, your governance mechanism is the metrics you put in place to measure progress toward your business outcome.
You measure progress and success based on business outcomes achieved, and the business can discontinue or reallocate funds without a change control process.
To paraphrase Brent Swanson again, as long as your product delivers sufficient value, ultimately resulting in an acceptable ROI as determined by the business – funding should continue. If that value drops (or the cost to support the value becomes untenable), your product may naturally be at the end of its lifecycle. It may be time to sunset the product or consider a new phase of the product (e.g. merging with other products, re-platforming, etc).
It’s important to establish metrics that tell you how you’re progressing toward your business outcome and set up a regular cadence to review those metrics. Your team should look at those metrics regularly to help you make product decisions, but you should also be prepared to review the metrics with your finance team and other stakeholders to make sure they’re comfortable continuing the investment.
Some key points when selecting those metrics:
- The metrics need to measure impact that your changes can actually influence. If your internal product is a news sales channel for your company, do not use revenue as your metric. There are way too many variables outside of your team’s control to get a good sense of the impact your changes have.
- Your metric should have a causal relationship with the ultimate business outcome. It’s a waste of time to influence a metric that has nothing to do with your desired business outcome. Don’t reduce costs if you’re trying to increase sales revenue.
- Your metric should allow for quick feedback cycles. If you’re looking at a metric that is an annual measure, you’re going to have to wait a long time to see the impact of any changes. The shorter the time span, the better.
- Be explicit about how you measure and calculate the metric and make sure everyone agrees on that definition.
- Make sure you can actually measure the metric, or put in place a means to do so as one of your earliest actions for the product. This is one place where tools and processes that autogenerate data comes in handy.
Accounting for the use of funds
Building software is not cheap, and even with product funding you often have to spend a bit of money up front to get something you can release to experience value (help you accomplish your desired outcome).
If your organization uses accrual accounting, you can capitalize some of those expenses to spread the impact to your profit versus if you counted all the costs of building software as operational expense.
Accounting for the use of funds as capital expense or operational expense is the last area that moving to product impacts. Although this is more a question that first came up when organizations started implementing agile software development practices.
To explain why, I’ll refer to this article from FocalOps:
As software investments continue to increase, and development teams adopt new methods of production, like agile, the accounting guidance developed in the ‘80s and ‘90s can seem foreign and lacking in application to today’s environment (ASC 350-40 and SOP 98-1 for Internal-Use Software and FAS 86 for Software for Sale or Lease). Fundamentally, the language of the guidelines was written when waterfall methods were predominant and tend to focus on the idea that software development progresses linearly with stop gates separating phases, just like a perfectly constructed Gantt chart. On the surface, this doesn’t seem to jive with agile methods which are more continuous and iterative, and focus far less on defining a particular phase with stage gates. This discrepancy often leads to one of the following negative consequences (in descending order of severity to the business):
- The blocking of agile adoption on the account of finance.
- The decision to avoid accounting treatment altogether to avoid dealing with complexity.
- The implementation of over-engineered processes (typically timesheet based) increasing overhead and/or decreasing utilization and impacting the relationship between finance and software development teams.
…
The third option tends to be where many businesses reluctantly end up. They set up a detailed timesheets system, often with onerous rules on time allocations and definitions, or perhaps require developers to somehow know the financial guidance when classifying their time, and then do a number of data merges in excel. At its best, this is a minor nuisance across the board with some risk in errors given excel based merging and reporting. At its worst, this results in significant wasted time and a very poor working relationship between finance and software teams.
There’s a better way to determine what proportion of time your team spent each sprint in working on new features (capitalization) or maintenance (expense). You can easily do that without requiring people to track time based on these assumptions:
- The cost of a fully dedicated product team in a sprint equals: 80 hours * hourly rate * number of people (you can of course expand that out if team members rates vary widely)
- The proportion of time spent on capitalized work in a sprint equals the proportion of Jira issues that are user stories
- The proportion of time spent on expensed work in a sprint equals the proportion of Jira issues in that sprint that are tasks or bugs.
Ken Rubin explains this approach using story points, but some teams (including mine) have stopped using points because they didn’t help us, and there are studies that have found that estimating by counting the number of backlog items is sufficiently accurate. Given the inaccuracies inherent in asking people to track time, this will give you a sufficient answer.
Here’s the key excerpt from Ken’s article:
Here is the good news: You do not need to track task hours in order to allocate development and maintenance costs appropriately. Instead, you can address cost allocation at a much more meaningful level—the size of each product backlog item worked on in the sprint. Many teams estimate the size of every product backlog item they bring into a sprint. These size estimates are typically expressed as points and are a very simple, reliable, and verifiable tool for doing proper cost accounting.
Let me illustrate by example. First, in most organizations the cost per sprint is a fixed cost. If you know who is on your team and you know the fixed duration of your sprint, you can very easily calculate your cost per sprint (Labor * Time = Cost per Sprint). Let’s say that cost is $20k/sprint.
Now let’s say that the team brings 40 (story) points worth of work into a sprint. If 30 points are associated with feature development, 5 points are associated with defect repair, and 5 points with knowledge acquisition, then at the end of the sprint the folks on the finance team would account for the sprint costs as follows:
Capitalize = $20k * (30/40) = $15k
Expense = $20k * (10/40) = $5k
It can be that simple! I’ve seen this approach used with companies to the satisfaction of both their internal and external auditors. It is easy to understand and apply consistently; and it requires very little effort to create accurate supporting documentation.
If your teams do not formally estimate product backlog items, you can still allocate costs. One way to do it is to define an average percent of the team’s time each sprint that is spent on new feature development vs. defects vs. knowledge acquisition. You can then use those ratios to divide up the costs. As long as your approach holds muster with your auditors, you should be good to go.
If you’d like an example from actual practice, Agile Alliance has a case study from Citrix Online that used the story point approach. They put this together as part of their Agile Accounting Standard initiative.
Give them what they want
The folks in finance serve an important function when they make sure that an organization is spending it’s money wisely.
Your product team should support that effort. You shouldn’t stray away from good product management practices or add a bunch of extra tracking and reporting work to do it.
Don’t take it from me what your finance folks are trying to accomplish. Talk to them. And treat your discussions like any good product discovery. Determine what they want to accomplish. Figure out the simplest thing that will work to help them accomplish it.
You’ll all be happier in the long run.