Thought Floor:The Challenge of Business Requirements vs. Business Processes

Guest Post By,

Michael Aston, Senior Technology Architect , MFG ADT Online, Infosys

Every so often I come across a project where the scope is to produce a like-for-like replacement of an existing system. I'll tell you right now, these projects are doomed to failure.

These projects occur for a number of reasons. Perhaps an existing product is no longer supported, or perhaps the business is trying to consolidate on to fewer technology platforms. In some cases the drive it to reduce recurring costs, in others the lure of a new technology has been irresistible. No matter the originating factor, they display the same barriers to success.

Firstly, in these projects the users aren't complaining about the existing system. It's a familiar beast, warts and all, and they're in their comfort zone using it. It's become the technology equivalent of your favourite armchair; maybe it's a bit scruffy and the cushions don't match, but woe betide anyone who suggests replacing it.

Secondly, the existing system will have been around for a while. Given long enough, people will adapt to anything and the alternatives will no longer seem viable[1]. In the case of established software, business processes mould themselves to fit the tools available, accommodating their quirks and peculiarities.

And so why does this spell disaster? Because while delivering a new system ensures months of business change preparation, retraining, transition planning, system lockdowns and post-release teething problems, the best you can hope to achieve is to deliver something as good as what they currently have.

And let's face it, you're not even going to manage this. Their business processes, and hence their requirements, are specifically tailored to the methods and peculiarities of their current system. Each adaptation of their approach to accommodate a limitation of their old system has now become an intrinsic part of their business process. Every feature they used just because it was there has now become a hard requirement for the new system. The only system that can ever fully meet their requirements is the one they currently have.

So what do you do? Go back to basics, challenge the assumptions, and keep asking 'why?'.

'Why does it work that way?', 'What are you trying to achieve?', 'What is the underlying business need?'.

And don't let them off the hook there. Dig deeper: 'What would happen if we did this?', 'Would the business objective still be met if we didn't do that?'. You'll need to peel back the layers of the current process to discover the original requirements, the ones buried under years of adaptation to accommodate the incumbent system. Once you uncover these, you're finally in a position to exceed the client's expectations and deliver something better than what they currently have.

This mind-set extends beyond the 'like-for-like' project. It's not uncommon for project stakeholders to become confused between the 'what' and the 'how' of a requirement. Too often you'll be told how the solution should work, rather than what it needs to achieve. It's the challenge of every system integrator to remember that the client isn't always right. When it comes to solving business problems using software, the integrator is the expert.

Each system and each product will have its own implicit approach to addressing the common business challenges in its domain of use. Allowing the business processes to flex to accommodate the technology platform increases the long-term likelihood of a successful implementation by encouraging the business to adopt best practices which have already been tried and tested by both the product vendor and their client base. It's inevitable you'll face resistance to change when pushing this approach; it's common to assume the current way of doing things is the right way.

But stand firm and you'll be putting your project on the path to success, and perhaps you'll even help them understand their own business a little better along the way.

[1] Consider the QUERTY keyboard - specifically designed to slow down typing speed (to stop the arms of the letters on the original typewriters from jamming), and yet still the de facto standard throughout the English speaking world.