The difference between IT specification and business requirements

I had a rude awakening this week when visiting an important customer.  We were trying to persuade this customer to buy more Blue Prism software to automate new processes, and early in the meeting we were stunned to hear a really negative reaction.  “Of course, I am really keen to do some more work with your product but we will have to persuade the business users who are very negative about your current solution”.

Looking back through our fault reports there was barely an issue raised in the last few months.  The IT people in charge of day to day running were reporting that everything was fine and “to specification”.  Yet the business users were reporting too many exceptions, not enough capacity, and functional issues.

Since our product is designed to be flexible and offer the agility to adapt quickly to new business requirements, this was highly embarrassing.

Turns out that the problem is that the business requirements have moved on, some of the people have changed who did not understand why some of the original design decisions were made, and when the business users asked the IT dept why the system didn’t do exactly as they wanted, they were told it met specification ,and that exceptions and responses were within SLAs.

The lesson I learned from this is to understand who your real customers are.  In enterprise sized companies this is often extremely difficult, but talking to the business users of the solution is always a good starting point.

One of the advantages a vendor solution has over an internally built one, is that the vendor is normally a specialist in a specific area and brings the benefit of working with many other organisations, hopefully with the expertise gained having been internalised into the software product.  Here we fell into a hole on this occasion.

I am so embarrassed, that I have scheduled a free review by one of our consultants, to reassess what the current problems are and what options there are for improvement, a redrafting of the business requirements as it were, not just in relation to our product, but the whole solution.  Then maybe we can get the IT spec changed to match?  And maybe that spec can include some flexibility to meet changing business requirements of the future – D’Oh!

2 Responses to “The difference between IT specification and business requirements”

  1. Francis Carden Says:

    I guess, if this wasn’t serious, it’d be funny. The truth is, yet again, it shows business and IT are often not aligned and “agile” integration tools are still used tactically and not strategically.

    I grew up in the “4GL” world where “users” learnt that they could have new things quickly (with quality) without waiting. They were so used to the mainframe “2 year wait” for enhancements, this was a real blessing. Seems we have gone backwards because IT should have been “listening” to it’s users here and know they could respond quickly. Have users really given up and just “accept” a “as specificed” response from IT. Have we gone this far backwards or do you think a one-off here?

  2. Alastair Bathgate Says:

    Hi Francis
    I detect that things are moving in the right direction here in the UK but there are always pockets of people who yearn for the old days. Maybe it’s a generational thing because new people entering the profession are innocently oblivious to the “old days” and are much more proactive and business focussed in my experience. I don’t mean that it’s an “age” thing, perhaps it’s a “how long have I been in IT?” thing…..

Leave a Reply