Measure Costs of Not Delivering Features
In my last blog post, called Measure Customer Value of Features, I discuss the importance of seeing the value of features from the customer’s perspective. But there is another perspective that the customer can sometimes have that is also important for us to see–the cost of not a delivering feature.
Sometimes we’re in time critical situations where we’re trying to beat our competition and get a feature out before they do or we’re trying to address a new market that’s exploding and the longer we delay the less opportunity we have.
Time critical situations like this can be very hard for a business to evaluate because there is opportunity costs as well as production costs. Markets are fickle and in some markets, being the first to market can make all the difference. This isn’t always true and in many markets being the highest quality, even if you’re not the first to market can give you the edge that allows you to ultimately dominate that market.
Opportunity cost can be real and in some situations can be measurable. Under these situations, I find that measuring these opportunity costs can be really helpful to management for making decisions.
Ironically, the one cost that I often find managers not noticing is their largest fixed cost, which is the cost of the team itself. If you have a team of 24 developers in your organization and their average annual salary is somewhere on the order of $100,000 for the sake of discussion, then with benefits and overhead and all the other costs related to having an employee, you probably are spending $200,000 a year on that employee, which for a group of 24 developers works out to be about $100,000 a week, every week or about five million dollars a year. That’s your burn rate.
The question is, are we creating at least that much value? Ideally, we would like to be creating ten times that value from the work that we’re doing. Running a development team is expensive but for many teams losing opportunities can be far more expensive. Just a few years ago I was working with the client and they saw an opportunity to modify some of their systems and capture a new market. The following year one of the developers told me that they made over $100 million by introducing just that one new product over the course of that last year.
In some situations, measuring the cost of not delivering a feature can have a big impact on the decisions management makes about what features to build next. This is important because the metrics that we track should be used to influence our decisions.
Note: This blog post is based on a section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software called Seven Strategies for Seven Strategies for Measuring Software Development.
