Cust. Sat: How do end-users feel when served by this group. Costs seem higher or lower with this model? Is it longer to be served by this group? How about the quality of the software over time.
Arguments Against Arguments for
Separate Maintenance Separate Maintenance
Cust. Sat: Users like the initial developers Initially less happy
Costs: Seem to cost less Seem to cost more
Delays: Slow and impacts other projects Perceived as Quicker
Quality: Mostly in the developers head Tend to be higher here
Size: Good model for small shops Better fit in big organizations
1 comment:
I agree and would like to add some other aspects to take into acocunt.
First the technical specificity of the application/code to maintain. If the programming language or the framework is largely used by several applications it is possible to gain from synergy, it is possible to share the same resources for similar applications.
secondly, the volume of calls/defects is also an important point. If such a volume is low or very low, the take-over effort from the dev. to the maintenance will probably never reach the break even. In such a case, the maintenance should be done in the development team.
Christian Huvelle
Post a Comment