True Cost of a Modification

[Steve King]

We are trying to come up with a formula for the true cost of modifications. So we can go in front of our steering committee and say the true cost of a modification not only includes the original development/testing/rework/implementation, but also costs such as daily support, training and maintaining the mod during an upgrade. To educate them that the initial costs are just the tip of the iceberg.

Any input on how to quantify that would be greatly appreciated.

 

[jolly]

Just tell them it will cost them their souls. That's approximately correct.

 

[theredcherub]

I opened your thread thinking it could be some interesting reading...

But the reality of this problem is that the cost can never be fixed down! It will always be a moving target...

It's the other areas/modules of the system that require additional support because thay are effected by mods that are hard to quantify. Uprade costs are relatively low assuming you will not be changing the mod at all. The initial development costs - well that is up to them!!!

 

[ShaunMorgan]

Get all the parties that are involved today to give a breakdown of how much time they spend supporting <Modification A>. Take a small, large, and larger modification and take through it with all parties.

Unless you just started doing modifications, you have these numbers somewhere, you just need to bring them all together.

 

[Chan Rana]

Lot more has been said on the estimates but you should also look at other way around.

There is a concept of code reuse. I am not sure if you are following this but its a good way to minimise the development efforts and cost.

I think you should also consider this.

Thanks,

 

[TAV]

No formula I nkow but if you get one post it;-)

My suggestion would be to track some modifications and then show the time and related expense over time. In some cases help desk tickets log the object and programmers track the objects for changes so you can see the IT input over time to maintain and then at upgraed you should be able to quantify the time as well. Now the user training part you would have to add in and should be able to get. Just some ideas.

Once you have a few examples you could try to use them to convey the concept but have fun getting management to understand common sense views and arrive at a logical conclusion;-) If they had that skill youwouldn't need to get any background would you? ha ha ha This is the real hard part Good luck.

 

[NikkiL]

Hi Steve,

A reasonable formula would be to start with the estimate for the actual development time, then take a percentage of this as follows:
- 10% for documentation (absolutely crucial for future upgrades)
- 25% for development testing
- 10% for business testing
- 10% for rework

I've never applied a percentage for implementation costs, as usually there is a full-time CNC person to perform all package builds and promotions.

Daily support and end-user training for the modification is not so easy to quantify - depends on the quality of the analyst, developer and user! But I think this would only be a significant factor in complex mods or enhancements - you could possibly use a percentage of 10%.

For percentages for upgrades I would scale the modification according to the complexity of the work. A simpler mod could take 25% of the original development, testing and documentation time to upgrade, test and document, while a complex mod could take 50%.

Custom objects would take significantly less to upgrade - but would still need some checking to ensure that logic, business functions and tables used are still accurate and relevant.

If a standard complex object (such as Invoice Print) has been copied and the copy heavily modified, it may be preferable to recopy the new standard object and reapply the changes, to take advantage of any fixes or new functionality in the standard object. In this case, the estimate for upgrade could be 75% of the original development, documentation and testing time.

Hope this helps,

Nikki