Friday, March 20

How [not] to build a business case for application modernisation

I read survey after survey that results in ‘modernisation’ projects coming top of the list of priorities for IBM i shops to undertake that year. It’s the same result year after year, so there must be no more old legacy systems out there! But you and I both know that’s not true, so wassup?

We’ve commissioned a few of these survey ourselves so I know that the data hasn’t been messed with to suit the sponsor’s agenda. Has the term modernisation become a modern day platitude or is it more a case of following that old adage about teenage sex: everybody is talking about it, very few are actually doing it, and those that are do it badly.

I used to think that IBM i shops were paralysed by fear. Fear of change in general or fear of deviating from the path of the mother ship, whether that influence is Big Blue or, say, the supplier of the original ERP package. Perhaps fear is too strong an emotion, and it’s really just a case of plain old confusion. For instance, it’s not clear to me whether IBM wants you to use the latest version of RPG, or re-write everything in Java, or web-enable with PHP or model your systems in Rational EGL (whatever that means). Microsoft would obviously like you to move workload over to their platform and let’s not forget all the third-party vendors, like LANSA, who each have a different take on how best to modernise your legacy system. One can easily forgive an IT executive for quickly appraising the landscape and retreating back to the comfort of what they know.

The advent of the Global Financial Crisis has made the answer clear – most IT departments couldn’t put together a compelling business case for modernising their core systems if their life depended on it. So the IT people surveyed want to modernise but they can’t get the funding. It’s the same reason why I don’t drive a Ferrari – there is often a will but never a way. It’s always been good practice to ensure that every significant IT project goes through a proper cost justification process. But I think we all know that during the good times people drop their guard and technology investments take on more of a faddish – or keeping-up with the Joneses - nature. Well I can promise you, from my every day experiences in the trenches of vendor land, there are no significant IT projects getting funded today without a compelling business case and a short-term ROI.

The bad news is that I don’t have a template that you can just tweak to produce your own business case – there are too many variables between applications and industries for a template to be meaningful. But I have learned that, when it comes to planning modernisation projects, you can only be sure about the things you can measure, and you can’t accurately measure anything without commissioning a prototype. This may sound like stupidly obvious advice, but I’ve lost count of how many times I’ve seen companies follow the guiding light of an incumbent vendor only to crash on the rocks. It seems that companies don’t always apply the same due diligence to existing advisors as they would to a new supplier.

Sure, a prototype will verify that the proposed solution does what it says on the side of the tin. But more importantly, a prototype is an opportunity to engage a potential business sponsor early in the process and that involvement sets you up well for compiling a winning business case. I’ve met IT people who are reluctant to involve somebody from the business too early in the process. I’m never quite sure what they are afraid of, but the excuse is usually couched in terms of business people not being interested in technology or something about “if they see it, they will want it tomorrow, and we’re not sure we're ready for that”. Whatever their reasons I can promise you that I’ve never had a bad experience by lining-up a business sponsor too early in the process. But I have seen modernisation projects fail to get off the ground due to a lack of proper sponsorship and the longer the IT people work in isolation the more disfranchised the business decision-makers become.

Any vendor worth their salt will offer to do a prototype. It need only take a few days, you should not be required to purchase or commit to purchase any software, but expect to pay a fair rate for their expert consulting services. Some companies ask for free prototypes but this is a false economy as you want the vendor’s best people on your project and, as the saying goes, if you pay peanuts then you get monkeys. Of course commissioning a paid-for prototype means that you now have to cost justify that expense so here are my ten top tips for explaining the value of a prototype to your boss:

  1. Demonstrating the vision to stakeholders, so that they are committed from the outset
  2. Securing internal commitment and building project momentum, particularly at board level
  3. Validating the business, process and technical assumptions made in the scope
  4. Testing the validity of the end-to-end concept, particularly any third-party integration
  5. Uncovering business risks and technical complexities before reaching the point of no return
  6. Extrapolating from real metrics in order to more accurately size the total development effort
  7. Testing round-trip performance to establish acceptable service levels and reveal bottlenecks
  8. Measuring load to more accurately size the hardware and network infrastructure requirements
  9. Limiting the initial commercial investment and risk – no white elephants
  10. Assessing the team’s ability to absorb new technology and to learn new skills

If you’re organisation is not willing to invest a few quid in gaining all those benefits then it’s a clue that you’re on to a hiding to nothing. I appreciate that just having a positive attitude towards prototyping is not a silver bullet. To create a thorough business case for application modernisation you will also need to consider the hidden costs of maintaining the status quo and paint a vivid picture of what the end game looks like for the entire systems architecture. I will post more on these and other topics about building a successful business case as we go through the year. But if you want to get started today, and hit the right groove from day one, then my advice is go find a business sponsor and make that first puppy dog sale.


Thom Davidson said...

I enjoy your blog and thought I would share an idea that certainly works in the United States. Sometimes the definition of the project can be as important as the project itself—at least when it comes to taking advantage of tax credits. Being part of an organization that includes a large regional CPA firm helps us to leverage all the tax advantages. Allow me to explain.

Many software development companies are unaware that the government offers generous research and development (R&D) incentive programs. Those that are aware often fail to capture the full extent of tax credits for R&D to which they are entitled. For example, many companies may be capturing relevant expenses from their programming cost centers, but not all qualifying R&D activities take place in traditional programming departments.

Good news! This is not limited to software development companies. Any organization that creates/defines a new project as R&D just might be eligible for a nice fat tax credit. Nothing helps a project like funding from Uncle Sam and you don’t have to work for AIG!

Martin Fincham said...

Potential financial support from one's government without having to be a financial services provider with a fatally flawed business model? Wow - I never knew that such wonders were possible ;-)

This is excellent advice [about R&D tax credits] and I will certainly be talking to my senior finance staff around EMEA to figure out what similar options we may have on a country-by-country basis. It's not often that you find a new win-win opportunity like this.

Thanks Thom.