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