If it can go wrong, it WILL go wrong

Share

You can never predict how customers will use computer systems, but one thing is certain, everything that can happen, will happen, whether you like it or not.

goingwrong.png

My company, systems@work, is the author of specialist software for expense management, and for the management of professional services organisations. Ours are highly configurable systems that can be used for a very wide variety of purposes. Even the terminology can be modified by the customer to suit the customer’s needs – one organisation’s ‘project’ is another’s ‘engagement’ or ‘case’, and yet another’s ‘investment fund’. Timesheets, attendance forms, expense forms, purchasing forms, absence request forms, planning, invoicing and reporting – these are some of the system’s possibilities, but each of our customers will set these up and use them in different ways. There is no right way to use our software, and however they set it up and use it, our customers must expect it to work.

Some years ago a few of our customers asked us to develop a new feature. Especially because end users might be scattered across the globe, they needed their administrators and first-line support staff to be able to log in ‘as if’ they are another end-user. And no, such end-users wouldn’t do any updates, they’d just be looking at the system as if through the eyes of the user they are trying to help, and yes, they wanted the end user to stay logged in whilst the administrator did his or her diagnosis, so both users could look at the same screen together.

So, we provided a highly restricted option called ‘Identity Switch’ that enables one end user, the administrator, we supposed, temporarily to log in as another.

Having two end users logged in to a system is uncomfortable. In our system, as in many, there are all sorts of temporary tables and sets of records that are identified by the end user’s name, and if two users are updating the same set at the same time you can create logical chaos. For that reason, we make it impossible for two users to login at the same time with the same user credentials. If they attempt it, the system says no.

Except, of course, for the administrator or support employee using the new Identity Switch function. We assume they will be careful, conscientious and that they understand the dangers of using Identity Switch to do updates in the system on behalf of the other user.

But you can never predict what users can do, and if there’s something you don’t want them to do you must prevent it, not merely advise them against it. Even if it’s more coding work up front, it will save you time later.

Over the last few months we’ve received a small flurry of reports of a few links between records getting lost.  It worried us, of course, and we spent many days investigating how it might have happened, finally discovering that it happened when Identity Switch was used. It turned out that Identity Switch was used for purposes way beyond those we had anticipated, not in exceptional circumstances, as we had recommended, but as part of the normal business process.

‘We warned you,’ we might say.

But what would be the point? We’ve still got to spend hours and hours diagnosing and repairing the problem.

There is no moral high ground to occupy if you’re a software developer. You can try to occupy it, but you’ll obtain no advantage. You simply cannot tell your users how your software ‘should’ be used, especially if you’re trumpeting its configurability. If it can go wrong, it will go wrong. If it can be ‘misused’ it will be.

In reality, there’s no such thing as ‘misuse’. If there’s something you don’t want your users to do, you must stop them doing it, not merely advise against it.

We’re working on it!

FPP – Estimating Fixed Price Projects

Share

I posted a blog a few days ago on Fixed Price Projects (FPP – A Frightening Acronym). FPPs frighten me because part of LLP Group (a part I’m happy to have sold) worked with the wonderfully open-ended Microsoft Dynamics business software products. We sold, scoped, estimated, and executed such projects poorly, to the extent that we made no margin at all, sometimes on hundreds of days of consulting, even whilst satisfying our customers. Our consultants and developers were no doubt excellent, but our sales processes and project management skills were insufficiently sophisticated and cautious.

Because of this I’m wary of FPPs, even if I know that they can be done well, can be controlled and can be profitable. To that end, I try to make sure that everyone in the company is aware of the risks and how they might be mitigated.

My last notes were about the Sales process. Here are some thoughts about Estimating.

estimating

Estimating

Estimating is a process that must involve both the sales and the consulting/development team.

It’s a time-consuming business. But FPPs get off to a bad start if we calculate estimates poorly on the basis of incompletely understood requirements, and half-baked solutions. Even ten free days up front might save hundreds of days later.

Of course, it’s the sales team that has to sell the project and who, in conjunction with management, must decide on price (for a defined scope), but our sales and management team MUST listen to what the consultants have to say. If they say they must know more about the client’s requirements, then the sales team must provide them with more. Never be tempted to think ‘Well, if I add another five days or so, that’s bound to be enough’. It isn’t.

And ALWAYS add contingency to your estimate. (And then more.)

In the end it is a commercial issue as to whether you knowingly ‘sell’ fewer days than you know that you need to execute the project. Whether that is commercially wise or foolish has nothing at all to do with the deadly sin of starting a project with inaccurate estimates of how much time the project will actually take you.

What if your estimate is insanely too low, and you discover that once you’ve started the project?

Well, it’s important when creating an estimate to make your assumptions explicit. This isn’t a slippery way of avoiding commitment, a trick that you’re playing on the customer. No, it’s an honest statement of the basis for your estimate. If it turns out that there are material facts that you’re unaware of, then you’ll be glad to be able to go back to the customer and ask for more time. And make sure that you make it clear that it isn’t your fault that you didn’t ask. You need to include a statement like this one in your proposal:

This estimate is based on materials provided by the customer and discussions with [named individuals]. Whilst we have built a certain level of contingency into our estimates to deal with the unexpected, the following assumptions are material, in that if they are incorrect our estimates may be materially wrong in either direction. These assumptions are [examples]:

  • In valuing your inventory you use only one method of valuation, weighted average valuation in local currency in conformity with statutory tax regulations
  • In valuing your inventory you value it only in one currency
  • You have no need for lot tracking of purchased, intermediate or final products
  • Etc’

 

And very importantly…

  • Your staff are motivated and committed to the process of implementation and will provide timely support as required
  • Your staff will be available for the time that we have estimated is required of them’

 

If possible you should build the estimation process as a first step of the project itself, or present this as a project stage where estimates and assumptions are confirmed. If necessary, give some free days to this, since your risk is greatly reduced by it, and you have a chance to demonstrate competence.

But if you do this it is also important that you build into your contracts an escape clause.so that both parties can terminate the contract or renegotiate it if the estimates or assumptions turn out to be incorrect.

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?