Pain-Driven Prioritization

How do you decide what's top on the priority list?

There's lots of methods, to be fair. I've always been a big fan of looking for the items with the largest Return on Investment (ROI).  The idea with this method of prioritization is that you have a portfolio of possible projects, and you figure out how much each will cost and what dollar value you could assign to the benefits of doing the project.

In the CFA curriculum, this is all discussed in the context of investments.  You want to figure out what a project is worth, so you make a few assumptions about the benefits, tot up what you know about the costs, net them out and project them back into today's dollars.  You end up either calculating the Net Present Value, or the Internal Rate of Return on investment, sort by that, and then make the biggest one your priority (to first order).  The discussion of these concepts is bigger than this little blog, but let me simplify.

All these things come down to always doing projects first that will give you the biggest bang for your buck.

And that's all good.  Figure out which project is the best spend of today's dollar to net you solid expected returns.  Some projects fold, estimations can be off, but if you have a diverse portfolio of projects and you're honest about your costs and benefits, these techniques can really work for you in the long run.

But what if you can't do that?  Some companies can't do this.  They either lack the talent of estimation, or the future is too murky to do projections, or all projects they look at have the same return, or even the organization is such a mess that any form of planning never really happens.  What can an organization like that do?

Well, one tech department I've worked with used, in part at least, a technique I always called Pain-Driven Prioritization.  Let's take the case of a very manual development process.  If you have three things that might possibly help the process along and only finite resources, what do you do?

You figure out what hurts the most and fix that.  If you can spend a few hours automating your build process, or your deployment mechanism, or how you manage tickets, it's time that will be saved down the road. Sometimes it's not the time savings, it's the friction savings.  If you can cost your developers fewer packet drops due to context switching and keep them focused on adding the business value that matters, you come out ahead.

You may be correctly thinking, "Well, this is still nothing more than bang for your buck, right?"

Precisely.

So why does this work, and why does it feel like such a different perspective to me?  Because it allows you to interview people and say, "Okay, this process is painful.  Where does it hurt?"  I've found, that if confronted with a question about how to improve their day, the response is usually about removal of roadblocks, or getting rid of annoyances.  It's hard for me to overestimate the power of improving people's days by removing the annoyances they face.

Ask any team, "Where is your pain?"  They can tell you.  Why have they not done what it takes to be out of pain?  Because they have goals, deadlines, business requirements to implement.  And they're not automatically wrong in doing this.

You can't sharpen your saw after every stroke, but you can't let it dull for years either.  Somewhere in there is the right responsible moment to pull out the rasp.

So take an assessment with your team.  Or extend it beyond the team to the business customers you serve. Where is the pain?  Let the pain be your guide.

I guess there's another name for this type of prioritization.  It's triage, and maybe we should begin using that term more in our communities when it comes to setting priorities.