Using ROI As A Constraint, Not An End In Itself

I had a fun conversation over instant messenger yesterday. The original subject matter revolved around a problem that the other person was having and how that problem was consuming a number of minutes per day with repetitive, tedious work. At the start of the conversation the focus was on a specific solution implementation and some general direction on how to get there. After a while, though, we started talking about the complexities of the proposed solution and potential high cost. At that point the other person mentioned that they probably don’t have the ROI to justify working on the solution during business hours.

The mentioning of ROI in this manner made me stop and re-think the conversation a little… it made me ponder how we are using ROI in situations like this and how it’s a flawed approach. It seems that we often want to jump straight to the solutions and then back ourselves down to a reasonable cost so that we can make some arbitrary ROI sound good.. Rather than backing an assumed solution that we want into a cost, though, what we should really be doing is determining the conditions that a solution must meet – including any specific timeframe and budget – and then find solutions that fit within those constraints.

To help illustrate this, here’s the rest of the conversation. I’ve consolidated a few of the times and removed a few lines, but the remaining text is from the conversation log, directly.

me: on the subject of ROI… there’s an interesting perspective change that you can use to help solve these types of problems. rather than using ROI to determine whether or not you can take on a task like this, use it to determine what the right solution for the problem is

me: you obviously have a problem. we’ve established that. rather than specify the implementation of the solution (i.e. a tool to auto-generate the stuff you need), look at it from a “process to solve the problem” perspective

me: the process to solve the problem is probably something more like “reduce the amount of time that we spend creating new solutions for these small projects”. you may even want to attach a metric to “time”… “reduce it by x%” or “reduce it to 10 minutes” or something like that. once you have a target like this in mind, you can also add the ROI bit to the solution: “must not spend more than x hours / days on the solution”. from there, you have a better perspective on what you can really do

them: Excellent points. Focusing on the process will obviously yield the proper solution, versus focusing my energy on a specific implementation. i.e., “it takes 20 minutes to do this. Let’s cut it in half and see if we still need/want to reduce it more”

me: exactly! here’s the fun part… when you make the statement “let’s cut the time in half” and “don’t spend more than x hours on the solution to cut it in half”, you introduce some interesting challenges to the people creating the solution. “this is our target… what are the challenges that we face in meeting this target?” list out the challenges… then brain storm solutions to each of the challenges, ensuring that the solutions lead you toward your target. those challenges will spark a lot of conversation, a ton of creativity, and you’ll end up with some extremely simple solutions to very complex problems

them: Which is obviously an approach that’s pretty universal. In fact, that perspective would certainly prevent a lot of “over-designing” of implementations, as well

me: yup

them: I feel like it’s all coming back to the YAGNI principle, no matter how I look at it