Friday, May 8, 2009

Justifying the Technology Transformation

This is the recipe: slice and dice your company’s view of technology, add a pinch of prognostication, sweeten the core issues faced by your legacy technology; then heat in the oven the mixture your business requirements represent. You can then serve up a fully baked, warmly prepared technology strategy.

Clearly, the key ingredient missing in this recipe is your actual budget. Even if there is a commitment to invest in IT, you should prove that it is worth the investment to undertake a transformation project rather than simply riding the legacy platform bandwagon for a little longer. If you decide on the latter approach, you might want to put this blog on the shelf for now and revisit it later, but if you want to show the need for investment, you’ll have to figure out how to go about convincing the CEO, and the CFO, and any other executive holding the purse strings, to open the company’s wallet.

All this is just my roundabout way of saying that, no-matter-what, you are going to need to develop a business case that shows the benefits of transformation in terms of dollars and cents; not just in qualitatively ethereal terms. You should be able to determine the benefits on the return of investment that the transformed IT will support.

In addition to the identified direct returns from the business team requesting the functionality, this ROI should include the monetized benefits derived from future time to market opportunities, reduced operational expenses (including cost avoidance), and if possible, estimated additional revenue resulting from functionality and features that would otherwise not be feasible with the legacy system.

How do you go about doing a business-oriented justification? Studies show that, in a typical IT budget, 80% is spent on system maintenance and the remainder 20% on strategic efforts[1] Indeed, there is little room for further maneuvering as IT budgets suffer from pressures caused by the global economic meltdown and you’re faced to allocate ever diminishing monies to “keep-the-doors-open” maintenance of systems that definitely must remain operational.

Ultimately, funding a transformation initiative can only come from a mixture of savings on day-to-day maintenance costs, supplemented with the injection of capital from business-driven initiatives. In the end, the business case should be framed with a combination of these benefits:

· Future cost savings due to the avoidance of maintenance expenses resulting from the use of newer technology. These savings can come from leveraging external operation services, removing dependencies on single vendors, opening the door to competitive pricing, and using lower cost commodity hardware and open source code. (Caveat emptor: Open Systems are usually cheaper, but not always! Check the fine print in those support license agreements.)

· Incremental revenues due to the higher effectiveness of the new technology. For example, fewer customer losses due to better service, better accounting and auditing information, reduction or elimination of maintenance outage windows, better business intelligence, and so on. For good measure you should also include estimated development cost savings associated with use of modern technologies and functionality enhancements.

· Added revenue generated by new business opportunities or competitive advantage enabled or supported by the new technology. The ability for the business to quickly implement a new promotion, or to define dynamic pricing based on more sophisticated customer intelligence or more targeted and flexible up-sell and cross-sell capabilities, scaling up to rapidly adsorb an acquisition, the ability to quickly connect to new partners via B2B services, are among the types of benefits you will need to quantify and elaborate upon.

You can try to reduce current operational and maintenance costs to help fund the initial investment for IT transformation but, needless to say, this might be extremely tricky to accomplish. Ironically, were you to accomplish this feat, you would also be playing with a doubled-edged sword. as you might be asked why there is even the need to proceed with a technology transformation, when the company can simply pocket the recouped funds.

Obviously, if there is money to be saved from conventional cost saving measures (renegotiating maintenance fees, reducing marginal staff, deferring expenses, etc.) you should do these as a matter of normal business. However, you will especially do well to identify those short-term savings resulting from the commitment to a strategic transformation direction. For instance, if the company commits to the technology transformation effort, you might be able to nominally reduce service-level agreements for non-critical parts of the current environment, but with the expectation that such an SLA reduction is a short term risk to be remediated by the earlier new project deliverables. Additionally, you might be in a better position to re-negotiate deals with your current vendors with the promise that they will be considered as potential suppliers for future strategic work. As part of the short term cost reduction, you might plan the short-term outsourcing of legacy operations, especially if your long term plan is to also outsource operations of the strategic system.

Be aware of that it is at this early stage of justification that the seeds of large project failures are often buried. The challenge always comes to this: if one is careful to include all possible costs and risks in the request for funding, you risk scaring away the support for the project. After all, executives are almost by nature risk-averse and afraid to accept cost estimates that while realistic, may suggest a grand level of investment.

The temptation then is to sugar-coat the request for investment by presenting best-case diminished cost estimates and over-promising on results.

Please don’t do that.

A better approach is to present a request that clearly delineates the benefits and costs for a series of deliverable phases so that the executive decision-makers can make informed strategic decisions on the level of investment they are willing to commit to. This way you will be able to limit the scope of what’s being promised in order to lower the initial funding request, while still announcing that you expect to come back in the future for additional funding as the project succeeds and proves it worth. Ideally, you will be able to define a first phase that produces benefits, but also points to subsequent phases that provide increasing returns with less and less additional investment. However, never propose a phase that consists simply of “infrastructure” positioning and therefore lacks a clear business case (see my rant below about the idea of business-justifying SOA on its own).

Most importantly, be wary of over-promising results in order to secure support for the new project. Remember, you are going to have to deliver on that promise! In the end, over-promising will only come back to haunt you and is not a worthwhile strategy. Seek at all times to follow this one wise dictum: Under-promise and Over-deliver.


Given that you will likely use a Service Oriented Architecture (SOA) as the backbone for IT transformation (more on this in followings sections), you might feel tempted to justify the endeavor on this basis alone. Don’t. There is no way you can make a business case for SOA. SOA is part of IT strategy; not a business strategy. SOA is all about “how” you will implement technology transformation and not at all about the “why”.

Developing a business case to justify SOA and then getting your CEO to sign a multi-million dollar check to implement it is not doable. Believe me; I’ve tried this! I once made a presentation to the CEO of my company naively asking for a gazillion dollars to implement this thing called SOA. He was a great CEO, he treated me with respect and he was so extremely gracious that he didn’t kick me out of the room when he found out there was no business case for it. Instead, he politely asked me to go back and make a business case for my proposal. Good luck doing that! It doesn’t matter that SOA just happens to be the most exciting thing to come out of IT since the invention of the one hour pizza delivery, or that it truly empowers a business by aligning its IT structure to business processes and goals, or that it does all this with potential cost-saving, open-source technology that can freely inter-operate via services, or that (write in-your-promise-here). What does matter is that your company will only fund initiatives that are framed around business benefits, and these initiatives are those that deal with “why”, and not “how”, the company does things. Yes, once the project has been approved and the process begun, SOA can and should become the solution’s backbone.

[1] Enterprise Architecture and New Generation Information Systems—Dimitris N. Chorafas