What’s your ROI?

Last week, we went over how our new Initiatives feature makes it possible for you to easily sync up your executive planning and strategy cycles. Whichever end you’re on — whether you’re an executive who wants to gain a better understanding of what’s actually happening on the business level, or you’re a developer who needs to know how to create the most business value from your work — Initiatives will help get you properly aligned. 

With Initiatives, you’ll know whether key business milestones are going to be met and whether teams are actually working on their most important priorities, and will be able to quickly locate and address your biggest risks, among many other benefits. Check out our full post on the topic to learn how it all works.

But running a successful company means more than just meeting milestones. At the end of the day, you have to be sure what you’re putting in justifies what you’re getting out. Or, even better, that every part of your business has a positive ROI. While this has always been the case, it’s become particularly important with the rise of interest rates. The days of free borrowing and careless spending are gone, which means companies need new ways to ensure they’re getting the most out of each dollar.

This is exactly why we built our Financials module.

‍

The challenge of making software measurable

Software development may involve an intangible product, but it’s no exception to normal financial rules. In fact, we’d argue that, as software applications continue to proliferate and the cost of developers continues to balloon, it’s become more important than ever to keep close track of your expenses. After all, at the end of the day, software is just another business process.

Except for one important difference: When it comes to software development, each day can differ wildly from the next. Although everyone may be writing out code, that code can be completely different depending on where your team is on a sprint, or which project they’re working on, or even their individual style. In other words, all of your outputs tend to be completely bespoke and entirely unique. (And if they aren’t, you may have an even bigger problem.)

What this means is that, with so many different units of measurement, getting an accurate ROI on your software development activities can be really, really difficult — although this sure hasn’t stopped folks from trying. This will often involve creating incredibly complicated spreadsheets or carefully tying BI tools into their processes. The result is a lot of work for not a lot of results. Edge cases tend to dominate, and even if they don’t the numbers can quickly grow static or out of date. On top of this, it can be hard for people to click through and understand these results. The entire process is just too complex.

But we think there’s another way.

‍

In order to properly understand the greatest variety of outputs inside their appropriate business context, it’s necessary to gain access to as many lenses as possible. Once you do this, you can look at your outputs from multiple different views, allowing you to measure, calibrate, and understand it better than you ever can on your own.

‍

Our solution and why it works

The big reason why people’s efforts fail is that measuring and quantifying absolutely everything is going to be next to impossible. Instead, we think that there’s a valuable middle ground that’s been overlooked. 

The idea is that, in order to properly understand the greatest variety of outputs inside their appropriate business context, it’s necessary to gain access to as many lenses as possible. Once you do this, you can look at your outputs from multiple different views, allowing you to measure, calibrate, and understand it better than you ever can on your own.

Let’s look at how this works on the ground.

‍

What goes in and what goes out

So how do we get all your financial data into Bloomfilter in the first place?

What we found is that, rather than doing complicated integrations with HRIS or ERP systems, it is far easier and efficient to just enter in the monthly spend data for each team manually. The reason for this is that almost every company should already know how much they’re spending per team. They probably even have those numbers sitting around in a spreadsheet. 

‍

Once we have this data, we’re able to use it as a key driver for some basic but very powerful analysis. For example, by playing with your different inputs, you can look at how much you’re spending per task or point each month, then see how those numbers are trending. Or you can see how your output is changing as your spend changes.

‍

Inevitably, with all this data now spread out at your fingertips, the next question that will come up is how you are allocating those resources.

Well, once you know what tasks and points cost, you can start doing a better job of estimating the price of all the various work you’re doing. This is the point when you’re actually able to talk about your software development process in the language of business.

But you can go even further. By using any of the metadata fields you have in Jira or whatever other project management system you’re using, you can start breaking down your analysis by different categories. This makes it simple to understand, for example, which aspect of an application is getting the most spend.

‍

Or how your spending is breaking down by priority.

‍

You can even do the same sort of thing for categories like build/run/maintain or capex/opex for financial reporting.

Personally, when I want to have a little fun with this feature, I like to use it to see how much money is being spent on the tickets that I put in.

Knowing if teams are working on my pet priorities makes it easy to determine who gets bonuses. (Kidding!)

‍

Wrapping it up

The reason our financials module exists is to translate the world of software development into the world of finance and business. This is a challenge organizations all over have had a hard time cracking because it can be so complex — but that’s exactly where we think they’re getting it wrong. 

With our approach, we’re rethinking how you can make your software more measurable and understandable for everyone. Instead of complexity, you get a series of simple manual data entries that you can then view across different lenses. This makes it possible to analyze your inputs any way you want — whether by team, project, task, priority, or whatever you think is most important.

It’s yet another way we’re making your SDLC more observable, predictable, and efficient.