It is an increasingly ubiquitous reality that all companies wishing to compete in today’s economy must embrace software as an integral part of their value chain (whether it be their product, part of their distribution strategy or their internal systems).
Software drives efficiency, which ultimately improves the bottom line. It is an increasingly important element of any company’s investment decisions and is no longer just in the domain of companies in the business of selling software. Surprisingly though, the relationship between finance and software development is weaker than many other functions. In defining relationship in this context, we are not referencing the actual interactions between functions, though they are certainly relevant, but rather the availability, sophistication and consistency of the financial measurement of the function itself across companies and industries.
To understand this more fully, it is important to discuss the primary role of finance as a communication channel, or, as is often said of accounting, ‘the language of business.’ Ultimately, the finance function translates operational information across company functions into a useful and consistent form for external stakeholders, typically in the form of financial statements and other financial analyses. This information is utilized and then flows back through finance to inform business priorities, performance goals and the strategies and capital to achieve them.
Because finance is the intermediary, it works with functions to translate their operations into useful financial information. This is why CPGs often employ brand finance leads into the brands themselves or why FP&A professionals exist to analyze the performance and cost effectiveness of production groups (whether services or manufacturing). Ultimately, these finance professionals learn the language of those groups and help both functions integrate. Conversation is a two-way street and one of the tell-tale signs of a good finance organization is their ability to speak effectively about the various functions of the business. It is incumbent on finance to understand how those functions execute and work to establish meaningful measurement.
When it comes to software development, the starting point in the whole conversation is to establish financial attribution to ALL efforts…products, versions and features. Without some method of financial attribution, evaluations of performance and future decisions are guesswork. It is important to note that this has nothing to do with the actual accounting treatment of effort as CAPEX or OPEX. The concept of capitalization often enters the discussion to soon, and while it is critically important for overall financial measurement and communication externally, it is not the reason or starting point for how the functions should integrate.
The first question to be asked (and answered) is “How do we determine financial attribution to our development efforts?”
The most obvious and commonly used method is timesheets. The basic math of compensation per hour times hours worked equaling value is obvious. But, the reality is that timesheets have many shortcomings on both the accuracy and efficiency fronts and many companies fail to realize that alternative methods do exist.
The chief drawback of timesheets is that they require overhead time from the development team to accurately document their efforts. This overhead time, while not tremendous, is certainly not a negligible amount in aggregate and has always been a historic nuisance to development teams. Furthermore, their accuracy is always in question as various rules get implemented like limiting to 40-hour work weeks to avoid changing hourly rates, or the actual hours themselves being logged once a week or less and clearly not being perfect reflections of effort.
While the chief benefit of timesheets is the flexibility in application to essentially any method of development, many organizations may have better alternatives based on the systems and processes they have (or are willing to have) in place. Chief among these alternatives are proportional points based models that leverage team utilization and allocate financial value based on story points (or tasks) completed.
The concept is that the story points themselves are the best reflection of effort that the teams have, and given the premise that they help manage their team’s capacity and workflow, it eliminates incentives of improper reporting at the individual level (which can be the case with timesheets). The chief assumption that must generally hold for these methods is that the story points within (and potentially across) projects are essentially consistently estimated measures of effort. For many companies, especially those in the SMB space, this type of consistency is easy to achieve and would be welcome to more intensive timesheet based processes. The major benefit of this method is it brings finance more directly into the development team’s processes, improving their understanding of the function itself, which, in the long run, improves the relationship and helps finance organizations be more effective in their role.
Ultimately, regardless of what is appropriate and what method a company prefers, the key is that a consistent method of attribution is selected and implemented each month. If your company does manage the software capitalization process, it is important to include your audit partner as you develop and implement your method.
