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.
Comments
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.