Opinion

How to be rational about software rationalisation

Warnings of the scale of disruption caused by the year 2000 software problem (no planes fell from the sky, after all) proved to be largely false. However, the year 2000 did present corporate IT teams with a stimulus to shut down old and inefficient applications which cost too much to run and were used by too few people, writes Nigel Hughes of Compass Management Consulting.

Almost ten years later, the current squeeze on corporate spending is proving an equally strong stimulus for appraisal of corporate software estates. As corporates seek to conserve cash and the public sector seeks out efficiency savings, there is a new impetus for radical change.

Complexity in the application environment is an important driver of increased overall costs in the IT function, so a focus on the extent of existing applications and those under development can produce big savings. Compass has observed some of the best performing organisations already taking advantage of economic pressures by replacing legacy systems and modernising their application portfolio. In particular, some organisations are showing a new appetite to consolidate the duplicate applications which have been accumulated through mergers, expansion projects and corporate re-structuring.

By streamlining the range of applications to be supported, IT operations can be significantly cut back. With the costs of maintaining legacy systems running at more than 70% of a typical software budget, lowering the application support burden can achieve swift, significant and enduring economies.

This portfolio analysis approach to making savings is proving more powerful in generating positive and sustainable change than a rushed decision to outsource application development.

IT buyers consistently over-estimate the savings they believe they can achieve through outsourcing or offshoring alone. Although the short term gains may look attractive, long term studies of efficiency suggest that there can be unintended consequences in the form of significant losses in productivity.

Compass is reporting cases where productivity of a software development effort has dropped by up to 60% as poor knowledge of the business function spoils efficiency. It seems that development projects struggle to recover - in cost terms - from a loss of functional expertise from among people on the ground who understand the business the software is supporting. With the additional pressures of fluid currency markets, (which have gone the wrong way for UK buyers of offshore services in recent months) it is crucial that candidate projects for offshoring are carefully chosen and that vital business analysis skills are kept in-house in order to maximise returns from an offshoring initiative.

Even if the business analysis is carried out onshore, poorly-planned offshore projects can still be hit by losses in development productivity of 20% or more. So while 40% lower offshore personnel rates look attractive to finance teams, the cost of additional management oversight, increased infrastructure spend, employee attrition, language difficulties and cultural issues can mean that the final charge is 20% more than a current in-house operation located onshore.

There is no doubt that carefully selected and well-managed development projects can be successfully completed offshore. However, the first step in any cost reduction exercise should be a rationalisation of the existing application portfolio. Companies taking this route are reporting reductions on annual software spend by 20-40% within 12 months. These initiatives are simultaneously delivering cash to the bottom line and freeing up resources to implement updated and cost-effective solutions.

Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in June 2009

 

COMMENTS powered by Disqus  //  Commenting policy