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

About Derick Bailey

Derick Bailey is an entrepreneur, problem solver (and creator? :P ), software developer, screecaster, writer, blogger, speaker and technology leader in central Texas (north of Austin). He runs - the amazingly awesome podcast audio hosting service that everyone should be using, and where he throws down the JavaScript gauntlets to get you up to speed. He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey, @mutedsolutions, @backbonejsclass Find me on the web: SignalLeaf, WatchMeCode, Kendo UI blog, MarionetteJS, My Github profile, On Google+.
This entry was posted in Coaching, Kaizen, Management, Metrics, Philosophy of Software. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • I help out on an economics course each year and the instructor likes to drive home a similar point. ROI by itself isn’t a good metric. Take two scenarios: invest $1 today and get $2 next year or invest $1million today and get $1.5million next year. The ROI on the first is much better but few people would take it over the second. You also have to consider the net present value.

  • Steve

    ROI isn’t really the issue here, perceived ROI is. Also, many IT departments are viewed as nothing but a cost within the executive branch which also cause no ends of trouble.

    For example, if a nightly process breaks say once a week, and some IT guy who’s on call gets up at 3am and somehow fixes the problem, that has no cost to the business (at least no perceived cost). So the next day when the IT guy who fixed the problem asks for some time to fix it he can’t prove ROI since fixing the problem is “free”.

    So when it comes time for the IT Manager/Director/Whatever to go hat-in-hand to the Executives to say “Hey, we’ve been doing nothing but delivering new features for two straight years, I really could use a couple of months to stabalize certain things.” he gets shot down because hey, that IT guy getting up at 3am is free.