Do You Consider “Opportunity Cost” In Your Analysis?

I’m a fan of live music, and I particularly enjoy music festivals. If you’ve never been to a music festival, you’re missing out. They usually involve multiple days of listening to music, dancing and having fun. There’s often multiple stages so one challenge is deciding which bands to listen to.

I was reminded of this fact last summer when I bumped into a friend of mine (who is also a BA) at a music festival. It turned out that we’d both created (and printed) spreadsheets showing who was playing when at what time. My spreadsheet even used color coding with green being bands we planned to see, and yellow being ‘backups’ (in case the first choice was too full, or there was some other reason we couldn’t get there).  Well, everyone loves a spreadsheet, don’t they?

Comparison and Opportunity Cost

Spreadsheets aside, this illustrates a point that is important in projects and product development initiatives too. Typically every action or decision has an opportunity cost associated with it. Taking one course of action means that it isn’t possible to pursue others (as time and budget is focused on the course of action that’s been chosen).

At a music festival, the opportunity cost is fairly easy to calculate. If I see Band A on the main stage at 8pm, I can’t see Band B on another stage at the same time.  I also can’t go to the bar (probably for the best), nor can I grab an overpriced hotdog. The act of deciding on an action means that other options are no longer open to me.

The same is true when it comes to deciding which projects to progress, which features to focus on, or which requirements to prioritize.  When writing an options paper, it’s usual to consider the impact of ‘doing nothing’, but in some cases it may be worth extending the thinking even further and considering what else could be done with the time and money.

When prioritizing requirements, there are always trade-offs. It’s desirable to deliver the features first that will enable the most benefit to be realized. This is certainly true, and this is something that I’m sure we all aspire to… but in reality aren’t things often a bit more complicated than that? There’s often resource contention (multiple development and testing teams, often with limited resources), organizational level challenges (code freezes, budget changes) and a whole load of other opportunities and threats outside of the immediate orbit of the project.

Sometimes It Makes Sense To Do The Second Best Thing

There might be cases when it actually makes sense to do the second most beneficial thing. Imagine there’s a high priority set of requirements. Everyone agrees those will yield the most benefit. However, the technical experts that need to work on them are also needed to work on some essential maintenance. Although systems maintenance and the art of ‘keeping the lights on’ is never as glamorous as delivering new features, it’s still super important.

Within the project, the logical decision is to go for the highest priority requirements. But, there’s an opportunity cost for the organization. If that action is taken, the maintenance is delayed. That might be a very bad idea, depending on the nature of the maintenance.

The key point here is that progressing the second best thing for the project might actually be the best thing for the organization overall.

Advertisement

Know Which Decision Options Are “Perishable”

Some options available to us “perish” if they aren’t taken. If you’re at an airport and delay deciding whether to get on the plane for too long, your option to board that plane will eventually disappear (as it’ll have taken off without you). The same is true at a music festival, if Band A clashes with Band B, then you have a straight choice to make. Choosing Band A means you don’t see Band B at that festival.

These are different from prioritization decisions where you can do both things sequentially. Delaying requirement A so the team can do some urgent maintenance probably doesn’t mean that requirement A will never be delivered… it’ll just be delayed. There will be an impact on the timing of benefits realization, but it’s not a binary “yes or no” decision. It’s important these types of prioritization decisions are separated from those where there really is one chance, and one chance only.

BAs as Facilitators of Decision Making

All of this leads to an interesting conclusion: An important and often overlooked element of the BA role is to facilitate decision making.  Whether that’s over prioritization of projects, feature requests, requirements or something else, we are on hand to analyze the different perspectives and ensure an informed decision is made.

Ensuring that we do this consciously, taking into account multiple factors (while keeping ‘opportunity cost’ in mind) is crucial. It’s one of the many areas where BAs add value!