The exercise of application rationalization is certainly complex. Reconciling the needs of many constituencies within an organization and reconciling those needs against a large and byzantine IT portfolio is a daunting task. In an effort to eliminate waste, streamline the IT estate and create a more “lean” environment to support, this kind of software engineering project must evaluate the needs of the business and assess a harvesting of the best components of the current application population. Common service layers can be created and new application support can be created in technologies like BPM. This is one facet of a business transformation process.
What about the financial justification for this kind of project? Is the cost an expense or an investment? The project will without a doubt require significant upfront investment in order to reap the back end rewards. Most IT organizations understand that this upfront investment will payback significantly in reduced downstream maintenance costs and improved business agility. How can the IT function acquire the support it needs to pursue this kind of project in a time when budgets are tight and expected benefit horizons are contracting? Is there a financial argument that can be constructed to justify the upfront expense?
By examining the structure of the rationalization project the financial impact may not be as debilitating as it may seem. Different aspects of the project budget can be recognized in different ways. The first, and most common arrangement, results in a ratable expense over the period of performance of services. The benefits of such a model include a predictable and consistent expense that allows for basic budgeting and planning. The second, and not so conventional arrangement, results in certain costs being capitalized and expensed over a much longer period, which significantly reduces the initial expense in year one. The benefits of this model include an expense reduction in year one as well as a predictable and consistent expense in subsequent years. The second arrangement is not as common, but can be applied in practice based on capitalizing costs associated with the rationalization efforts and depreciating those costs over the useful life of the related assets (IT software and/or hardware).
The amount of the project that can be capitalized will depend on the amount of project expense that is devoted to upfront analysis and assessment versus the execution and deployment of the new environment. Analyzing hardware and software costs, network build out (if required), physical construction, and the costs associated with various stages of the SDLC will help determine how much of the true cost would be depreciated over the life of the application.
In his post IT Budget Constraints Drive Application Modernization, Mike Vizard believes the time might be right. He cites a Forrester Consulting and HP study which found, “…more IT organizations appear willing to take on the risks associated with an application migration in order to accommodate substantially lower IT budgets that appear to be with us for at least the next several years.”
Has your finance organization partnered with IT to understand all of the financial options available to support a project of this kind? Have you been successful budgeting for a project in this manner? Perhaps this solution can help organizations with the “courage” mentioned in a previous post titled “The Next Frontier in IT TCO Reduction”.
Next step, let’s look at a project budget in detail to highlight the exact benefits of our second approach. If you have examples, comments, questions or suggestions, please comment here and we will look to incorporate your feedback.





[...] BPM Financial Justification – Doug Mow Most IT organizations understand that this upfront investment will payback [...]
Adam – I agree, most IT organizations understand this. It’s convincing finance and getting approval for the project that is the challenge, isn’t it?
Financing rationalization projects for the enterprise is a key issue. Enterprise Architects will almost universally recognize the need to rationalize, but when ever they try and get a project started, the funding becomes a blocking issue.
Learning how to remove the funding barrier is critical. Only once Enterprise Architects can rationalize the enterprise architecture will they be able to accelerate the business results made possible by recent technology innovations such as SOA, BPM, MDM, and Web 2.0.