After running a few projects that refresh technology rather than add functionality, I've noticed a few recurring themes:
- Technology refresh projects are more likely to go over budget/schedule; projects that provide incremental new features are less likely to exceed budget & schedule estimates.
- Development teams are more likely to underestimate technology refresh projects.
- New functionality tends to have well-defined requirements.
- Old functionality is always a journey of discovery, especially on widely deployed products with history of customer-driven fixes and enhancements.
- A large part of this hidden legacy only comes out after the team has a chance to make serious headway with refactoring.
All of that makes early feasibility assessment and ROI analysis on such projects challenging.
I've tried two techniques to address this. One technique is to add a constant tax on top of team's estimates, but that can be crude and imprecise, since refactoring projects are not born equal. Another is to delay estimate and schedule projections until the team has spent reasonable effort flushing out the hidden costs. This does not always work though, since sometimes such reasonable effort in itself is expensive, and/or the business requires early prioritization.
I'd be interested in collective wisdom from people who've run such projects. How can I get get reasonable predictability when planning a technology refresh?