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


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.’


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?

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

  1. Having been involved in many upgrades and new implementations in the past, I totally agree with your comments about how frustrating it can be for both the supplier and user when it comes to determining just what gets left out – either intentionally or accidentaly.
    With upgrades – particularly if they are major – my approach has been to treat the project as an opportunity to review current practices and to adapt them if the new software can show something easier or better.
    However, as you say, there will always be the issue of budget in such projects where the sponsor(s) look for best value for money.
    We are about to make a move from Sun v4 to v6 and we are fortunate to have the time and budget in this case to really look closely at what we have done in the past and how we might improve things. Such an upgrade project is a once in a long ting time opportunity to do this as it is so much easier to do a step change rather than “tinker” with the end result once implemented.

    Liked by 1 person

  2. Hello Adam, I enjoyed your post. I have been implementing systems for about 15 years now as both a sponsor/Project Manager and as a consultant. I believe there are a few key reasons for the result you describe. As you mention, budget is a main consideration for all of the companies with which I have worked. Scope is often cut to fit the budget as other areas of a project exceed budget and schedule. In addition, training is also often given secondary priority due to cost and time constraints. I have also found that many administrators of a newly implemented system do not have the time or the training to implement may features of complex systems. Even in organizations with ample budgets, people are often very busy in their jobs and are not given the time or make it a priority. Overselling is also common to win a contract at the lowest price is also a problem.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s