3 ms·

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

by thorax 19y ago

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: * 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.

mdemare 19y ago
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. *mdemare eyes himself warily*
- thorax 19y ago
  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=pvOwoUYoNUFTmGZhwyjK4OA&hl=en 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.
- anewaccountname 19y ago
  >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.
19y ago

by thorax 19y ago

mdemare 19y ago

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. *mdemare eyes himself warily*

thorax 19y ago
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=pvOwoUYoNUFTmGZhwyjK4OA&hl=en 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.
anewaccountname 19y ago
>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.

19y ago