A long time ago I realized that people mean different things when they say 'priority'. If you only mean the 'value' of a certain task, then that's not a good way to prioritize, IMHO.
I've changed my model to prioritize strictly according to return on investment. I.e., how much value I or the company receives for unit of work.
In my professional project management and in my company, here's the algorithm that I pretty much use for every sort of task prioritization:
(1) I put together a list of items
(2) I put a relative cost (RC or C) associated with each item-- for a task list this tends just to be the hours you predict you'll spend.
(3) I hide those costs and then add some number that represents the relative business value (RBV or BV) of each item. (More on this in a second)
(4) I unhide things and then put another column that just calculates RBV/RC which indicates the return on investment (ROI) for each task.
(5) I then sort it all by ROI and work my way down the list in ROI priority order, always working on the tasks that offer the most ROI, I adjust values and costs (and re-sort) as my needs change, work completes, and as my understanding of each task changes.
The units used to value each assigned task is not really important. It's only important that tasks have a value that makes sense relative to each other.
For example, if I have these tasks:
* Setup tech support email account
* Improve usability for site logon page
* Write a blog article about our recent features
I might then give these costs:
01 hour - Write a blog article about our recent features
01 hour - Setup tech support email account
16 hours - Improve usability for site logon page
Having a tech support email account, I know that's important and I must have it, so it gets a high value. In this case, I'd say "Improving usability" is something we could survive without, but I firmly believe it could increase our revenue.
I might then give these relative business values (I'll just say points):
200 pts - Write a blog article about our recent features
10000 pts - Setup tech support email account
5000 pts - Improve usability for site logon page
When I calculate the ROI and sort them, I get this list that I work from top to bottom:
10000 pts/h - Setup tech support email account
313 pts/h - Improve usability for site logon page
200 pts/h - Write a blog article about our recent features
As long as when I add new tasks, I evaluate them against the other values and costs to ensure they're all relatively correct, the list always sorts to provide the tasks with the 'biggest bang for the buck' at the top.
I believe that the challenge is not "how to prioritize given the relative business values" but "what is the most important thing to be working on." Getting a business moving can be a little like opening a combination lock: you can be working on the right things, but if you don't focus on them in the right sequence they may not have any impact.
That being said, I try to capture items like that via a constantly evolving list (which is pretty much necessary no matter what). The relative business value of the next item in 'the sequence' would be higher that day/week than than it would be otherwise and would bubble to the top if it was the highest return on investment.
Likewise, it's possible for the 'cost' of certain tasks to drop/rise based on what's happened recently (i.e. you just learned more about something, or you're in a really productive mood or office setting).
In the end, my ideal would be just to figure out what's the highest return for my time __right now__ and work on that. I.e., it's a continuously updating function and the list is never set in stone.
We actually juse use Google Spreadsheets, and it's simple enough that I use it for personal stuff sometimes, too. It sounds far more complicated than it is.
Here's an example sheet that you should be able to copy via Google's menu:
Having used this specific approach on many projects, there's considerations that should be kept in mind that I haven't solved 100%:
It's difficult to track dependencies between tasks and have those sort efficiently. As a human you have to realize the sheet is a tool and that you have to look to catch these things from time-to-time.
If you're not careful, you can defer 'infrastructure' tasks that have no obvious/direct BV. I work around this by temporarily having infrastructure tasks inherit the combined BV of all things that they'll help and for all tasks to add the infrastructure item's cost to theirs.
There's probably a more accurate formula for dependents and dependencies to use, but I find that if you have 99 tasks dependent on an infrastructure task, it's not unreasonable to say that task is pretty durned important to open 'doors' for the company.
For example, refactoring tasks often fall into this category. Changing from an Access database backend to a MySQL backend might not give you immediate ROI, but the sheer number of things that open up to you as possibilities after that need to be considered somehow. The conventional naive approach might not get you there without the item inheriting some of the value.
>I don't have Excel, so I'll start writing a Ruby DSL to implement this right away.
You didn't listen to a word he said. I mean, just do the smallest list possible that you can fit into your head (so that you don't need Excel): this can only have two items if you want--find an Excel alternative; write a Ruby DSL. Weight those the way he said, and you will end up crossing the Ruby DSL off of your list.
Do you add an NPV to account for not getting the return until some date in the future? I.e., a 10000 pts/hr task might be better prioritized after a 100 pts/hr task if the duration of the first is two years and the duration of the second is two days.
(Yes, these are silly and inflated and completely hypothetical. I'm interested in how you solve them within your structure, as I'm a huge ROI fan.)
Comments
I'll start by saying I'm a weird guy.
A long time ago I realized that people mean different things when they say 'priority'. If you only mean the 'value' of a certain task, then that's not a good way to prioritize, IMHO.
I've changed my model to prioritize strictly according to return on investment. I.e., how much value I or the company receives for unit of work.
In my professional project management and in my company, here's the algorithm that I pretty much use for every sort of task prioritization:
(1) I put together a list of items
(2) I put a relative cost (RC or C) associated with each item-- for a task list this tends just to be the hours you predict you'll spend.
(3) I hide those costs and then add some number that represents the relative business value (RBV or BV) of each item. (More on this in a second)
(4) I unhide things and then put another column that just calculates RBV/RC which indicates the return on investment (ROI) for each task.
(5) I then sort it all by ROI and work my way down the list in ROI priority order, always working on the tasks that offer the most ROI, I adjust values and costs (and re-sort) as my needs change, work completes, and as my understanding of each task changes.
The units used to value each assigned task is not really important. It's only important that tasks have a value that makes sense relative to each other.
For example, if I have these tasks:
I might then give these costs: Having a tech support email account, I know that's important and I must have it, so it gets a high value. In this case, I'd say "Improving usability" is something we could survive without, but I firmly believe it could increase our revenue.I might then give these relative business values (I'll just say points):
When I calculate the ROI and sort them, I get this list that I work from top to bottom: As long as when I add new tasks, I evaluate them against the other values and costs to ensure they're all relatively correct, the list always sorts to provide the tasks with the 'biggest bang for the buck' at the top.I believe that the challenge is not "how to prioritize given the relative business values" but "what is the most important thing to be working on." Getting a business moving can be a little like opening a combination lock: you can be working on the right things, but if you don't focus on them in the right sequence they may not have any impact.
True, I agree.
That being said, I try to capture items like that via a constantly evolving list (which is pretty much necessary no matter what). The relative business value of the next item in 'the sequence' would be higher that day/week than than it would be otherwise and would bubble to the top if it was the highest return on investment.
Likewise, it's possible for the 'cost' of certain tasks to drop/rise based on what's happened recently (i.e. you just learned more about something, or you're in a really productive mood or office setting).
In the end, my ideal would be just to figure out what's the highest return for my time __right now__ and work on that. I.e., it's a continuously updating function and the list is never set in stone.
I think I'm weird too, because I love the idea. But please tell me you only use this for work.
I don't have Excel, so I'll start writing a Ruby DSL to implement this right away.
We actually juse use Google Spreadsheets, and it's simple enough that I use it for personal stuff sometimes, too. It sounds far more complicated than it is.
Here's an example sheet that you should be able to copy via Google's menu:
http://spreadsheets.google.com/ccc?key=pvOwoUYoNUFTmGZhwyjK4...
Having used this specific approach on many projects, there's considerations that should be kept in mind that I haven't solved 100%:
It's difficult to track dependencies between tasks and have those sort efficiently. As a human you have to realize the sheet is a tool and that you have to look to catch these things from time-to-time.
If you're not careful, you can defer 'infrastructure' tasks that have no obvious/direct BV. I work around this by temporarily having infrastructure tasks inherit the combined BV of all things that they'll help and for all tasks to add the infrastructure item's cost to theirs.
There's probably a more accurate formula for dependents and dependencies to use, but I find that if you have 99 tasks dependent on an infrastructure task, it's not unreasonable to say that task is pretty durned important to open 'doors' for the company.
For example, refactoring tasks often fall into this category. Changing from an Access database backend to a MySQL backend might not give you immediate ROI, but the sheer number of things that open up to you as possibilities after that need to be considered somehow. The conventional naive approach might not get you there without the item inheriting some of the value.
>I don't have Excel, so I'll start writing a Ruby DSL to implement this right away.
You didn't listen to a word he said. I mean, just do the smallest list possible that you can fit into your head (so that you don't need Excel): this can only have two items if you want--find an Excel alternative; write a Ruby DSL. Weight those the way he said, and you will end up crossing the Ruby DSL off of your list.
Do you add an NPV to account for not getting the return until some date in the future? I.e., a 10000 pts/hr task might be better prioritized after a 100 pts/hr task if the duration of the first is two years and the duration of the second is two days.
(Yes, these are silly and inflated and completely hypothetical. I'm interested in how you solve them within your structure, as I'm a huge ROI fan.)