Mutual Frustration – Why do IT systems users wait so long for features that already exist?

Share

I attended a conference recently where, by chance, I met someone who’s using the expense management system that I design – expense@work.  It’s always a little alarming when you meet a real user since you must expect them to be honest, and there are no better judges of what you’ve done. This one was direct:

‘I hate it,’ he said, with the kind of mock fury that told me that he knew he was exaggerating and didn’t really want me to go away and kill myself.

‘Why?’ I asked.

‘Well, it’s so out of date. I can’t attach images to my expense claims, and I can’t use it on a mobile device,’ and so on.

‘But you can,’ I said. ‘We’ve had those features for years.’

‘Then why haven’t we got them?’

‘I don’t know.’

frustration

It’s so frustrating, but this happens time and time again. And not only with our own software. We also sell and implement a financial system, SunSystems, and again, we often have to deal with users who want features that we have, but who aren’t getting them.

This is actually a widespread problem in system implementation and the end result seems to be unnecessary reputational damage for the software author.

Why does it happen and how can it be avoided?

It happens because system implementation is a lengthy, expensive and risky business and end users don’t often determine what’s on the list of features that they’re going to get. Sponsors and project managers on the client’s side have a highly controlled, and usually narrow, list of objectives, and their criteria of success won’t usually include the implementation of features that are merely ‘nice to have’ but not necessary.

That’s why ‘nice features’ don’t make the list during an initial implementation, but it doesn’t explain why nice new features don’t get implemented later as soon as they become available.

The problem is that once a system is implemented, the policy becomes ‘if it ain’t broke, don’t fix it’, so new versions with ever more up-to-date features, don’t get implemented either. And this is eminently sensible, because upgrades take time, often go wrong (for a while at least), and cost money. Upgrade projects are sometimes almost as large, expensive and risky as initial implementation projects, even if the software automates many aspects of the upgrade (such as updates to the database).

Software authors want their software to be liked by their end users. End users want ‘nice’ features. The obstacle lies between the two, in the conservatism of the client’s project managers and IT department.

Sadly, I can’t see what’s wrong with this. ‘Conservatism’ is a very sensible policy with business systems. The tragedy is that result is frustration on one side and unhappiness on the other. is there anything we can do about it?

I ask this question without knowing the answer. I wish I could find a way to deliver new features in software without risk or disturbance. But this is difficult. Business software isn’t like a desktop productivity tool. The problem is that what you do in one corner of the system can have unintended consequences in another corner. And when a system is implemented for a client it’s often integrated with lots of other systems, so a change in one corner of our part of the whole, can disturb a corner in another part that isn’t within our control, as authors of just one part, at all.

To some extent this problem is solved in ‘cloud’ or ‘hosted’ solutions, because authors then control the version that an end-user uses, and can introduce and publicise new features without obstruction from intervening project managers.

But ‘cloud’ and ‘hosted’ solutions aren’t always suitable when it comes to complex business software, especially when the software must be integrated with a client’s own systems. When there is deep integration, conservatism rules, and must do so.

And yet, it’s so frustrating to meet end-users and to have to repeat time and time again,’But our software CAN DO THAT!’

Any ideas?

Don’t Take the Source Code

source code

The most difficult questions are the most open ones. What would you do if you were Prime Minister? Better to be asked specific questions: What would you do about school dinners, or Iraq, or capital punishment, or conscription, or food labelling or the railways? If the questions are more particular then you’ll probably have an opinion, or at least something to say.

I remember English composition lessons at school. Write a story, the teacher would say, and I wouldn’t know where  to begin. Write a story about four-eyed Martians and I’d know where to start. Complete freedom is paralysing. When everything is possible, nothing comes to mind.

For somewhat different reasons, being able to do anything at all with business systems is also terrifying. Partly, perhaps, because you don’t know where to start, but ,mainly because you don’t know when to stop.

Although nothing falls entirely into one or the other category, you can roughly divide business systems into those where you get the source code, and which you can do anything with, and those where you don’t get the source code, where possibilities are constrained.

I like constraints. When there are constraints, possibilities are very many fewer, and there are clear choices to make. This is the better situation.

Of course, if you get the source code you can build something that does exactly what you want to do (well, what you want to do NOW), but it will take you forever and cost you an infinite sum. When you don’t get the source code you may get 90% of what you want at a reasonable price, and soon. Moreover, you will find upgrades immensely easier.

I worked years ago, as a consultant, with an oil company that decided to take one of the largest business systems in the world, adapt the source code and implement it globally. The project was immensely expensive, took far longer than planned, and when the system was ready it was already out of date and impossible to upgrade. The system was abandoned in favour of another even bigger one that needed less adaptation.

And at LLP Group, a software reseller, where I work, we had two divisions – one selling Microsoft’s modifiable Dynamics software, where our projects were often disastrous, and one selling Infor’s non-modifiable software, where our projects were manageable, satisfying and profitable.

Don’t touch the source code!

Share