Thursday, 16 May 2013

When customers spend way too much on software....

If you work in anything related to IT, you have probably experienced the dreaded, "oh? You work in computers? Can you fix my printer" or something very similar. To the uninitiated, IT is a single entity, you either know about it or you don't

The problem with this is that most people now think that since they have an email address and use a few computer programs, they are now "in" IT and to buy something in, such as a new web site or even, God forbid, a business application, is easy right? These insecure people try and cover over their ignorance when discussing backup policies, scalability and choice of hardware by pretending that they do understand and will chastise the expert when their idea for a button is apparently going to cost another £1000 for reasons that are not immediately obvious. On the other side, a supplier will gladly regale the customer with buzzwords, strange marketing names for standard things or bedazzle them with proprietary systems that add no value, cost too much and lock the customer in.

The problem we have now, though, is that most companies realize they need some kind of IT, at very minimum a web site and so all these people are let loose onto the technical supplier community who offer these kinds of services and there don't seem to be any hard and fast rules about how to go about this effectively. This is, of course, very similar to getting a builder or plumber in but the stakes are actually, often, much higher. Spending a few hundred more on a plumber is annoying but spending 1000s on a piece of business software which, at best, might add no value to the business but at worse might make it less efficient and cost more overheads can be the death of a company. This is pressure that many of these 'buyers' don't seem to be able to manage properly and they end up putting pressure or unrealistic expectations on their IT suppliers. I know one company who spent £200Kish on basically a conference booking database which, to be honest, could have been written from scratch for much less but this is what happens when the stakes are high and the expertise (even possibly of the supplier) are low.

So what do we do about it?

Well, firstly, we could employ someone with experience to manage these projects. People who know the lingo and who can tell a supplier when he is wrong and who can then translate language in both directions between the supplier and customer. Of course, this might not necessarily work very well because then you need this consultant to be trustworthy and, naturally, they are likely to tell you why they are the best choice, even they are a complete chancer! It only moves the problem, it doesn't solve it sadly (unless you happen to already know a capable person of course).

We can buy off-the-shelf products. This is not as bad as it sounds. One of the things I've noticed is the tendency for companies not to accept the built-in functionality of something and therefore feel the need to create bespoke i.e. expensive software. With off-the-shelf software, you will usually know or be able to find out what functionality is included, you can try the software out and see whether it is correct for your staff and the pricing is often very straight-forward. This also goes for web sites, since now you can buy basic off-the-shelf sites with minimal customisation for not very much money. It might be way cheaper overall to miss-out on some functionality but buy something cheap and standard.

One other issue that is often missed is that unless the company understands its own business processes and has optimised them, it is almost impossible to support this effectively in software. The simplest software always mirrors the most optimal processes whereas scatterbrain processes (possibly implemented by control-freak managers for their own ends or evolved over time so that none of the current staff even know why it works like that) create complex software which will be costly and almost certainly be riddled with bugs. Best case, it works fine but is impossible to modify later when the customer changes their mind.

I am currently of the opinion that the software lifecycle process is as strong as the weakest link. While there are uninitiated customers, untrained suppliers, egotists, poor communicators and poor business people, all of these sequences are, by definition, fragile and potentially expensive.

The answer, therefore, is to remove people as much as possible from the process. This means specifications and documentation. It means that software is not changed until the changes are signed-off and agreed. It means that a design costs x and a re-design costs y. It means that changes are managed by process ABC and most importantly that these procedures and processes are continually refined and adjusted to suit. No-one wants a one-line text modification to take 2 weeks of paperwork to sign off but equally, it is foolish in this poison business that we're in, to "just make the change" when a customer then comes back and claims they never asked you to make the change.

This requires suppliers to manage the process because they are the domain experts. These processes are explained up-front, along with day rates or unit rates as appropriate and I would also suggest a few examples of where a poorly managed project from the customers point-of-view costs double or more that of a well-managed project so the customer can appreciate why and how indecisiveness or pickiness is an expensive business. At this stage, if the customer knows that something is likely to change often, they can decide up front to build-in the functionality rather than manually changing things everytime the change is required.

It is time that software suppliers upped their anti. It is time to stop acting like people sitting in garden sheds and learn about quality assurance, communication, appropriate contracts and general business sense otherwise I fear their stress levels will continue to increase along with businesses who fold because they cannot charge the amount of money they should be for a project that they know should have cost much less.
Post a Comment