views:

40

answers:

2

we have a number of functional deliverable planned for 2010 but we also have a technology agenda (architectural refactorings, consolidation, upgrade a platform). any suggestions on the best way to include these in a roadmap to help the business understand why they are important.

one option is just saying trust us as this is the right thing to do to keep everything healthy but i would like some better visualization if possible

+1  A: 

Show how support time, time between failures, number of problems should go up if you won't do the change. Each technology has it's time limits, end of support from the manufacture, and regular life cycle.

Example - if you use MFC - you can show that programming a simple task in MFC is 3 times slower than in winforms. so after x months, the benefit from not upgrading will be lost.

with equipment it is even easier, as the older the equipment gets, the more mal-functions there are and it is easy to show (usually after the 3 years covarage everything starts to break, and I think it's planned like this. it didn't use to be but these days it does).

with infrastructure - again - if you have oracle 7.6 - show how much more time (money) you spend on administration and how less will be spent in 11g.

ect. ect. ect.

eventually manager wants to see ROI... TCO... BLA BLA BLA so you need to give them that.

Dani
There is something more.. it used to add something to my claims in my last position, if good people get bored with old technology, good people won't stay.
Dani
i agree with all points above, but i am trying to figure out the best way to visualize this . . .
ooo
Excel Graphs.... or whatever you use. show that staying in same place will cost more money in the long term, and add the "un-messured" factor of HR - that can't be measured directly by money, but effects the team performance...
Dani
+2  A: 

Being a bit cynical about it, I would say phrase every thing in terms of money. If you can't re-write your technical agenda in terms of money made or money saved, then why are you doing it at all?

Also, there is an article on "technical debt in financial terms" that I found very useful at:

http://forums.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx

One of the more interesting points, to me, is "One of the important implications of technical debt is that it must be serviced, i.e., once you incur a debt there will be interest charges."

There is a brief follow up at

http://forums.construx.com/blogs/stevemcc/archive/2007/12/12/technical-debt-decision-making.aspx

Bigwave