Software Mistakes

Retiring the Old System Too Early

When new software projects start, the idea of retiring the old one often takes a life of its own and the IT staff become desperately keen to delete everything, turn the machines off and recover the rack space in the server room. Although there might be technology arguments for yanking out the old system as soon as possible, any plan for the rollout of a new system must include keeping the old one running, not only until the go-live day, but for some time afterwards.

The old system will be needed, at least, for historical information and, at most, a fall-back in case of delay.

The problem is that retiring old systems is easy and commissioning new ones is hard, so if two such projects are planned to finish by a certain date, retiring the old system is very likely to be finished on time and starting the new one is very likely not to be finished on time. And then you have a crisis because you don't have any sort of system running! Trying to finish a project in an environment of crisis usually makes things worse, and instead of a wonderful new system you have a disaster that barely keeps going.

Given a last minute problem with the new system, would you rather have staff using the old system, inefficient though that may be, or writing everything on bits of paper? As strange as that “solution” sounds, it happens all the time, all over the world and in all industries.

New software systems are often deployed along with new hardware, and it's usually too difficult to recreate the old software on the new hardware. Fortunately, “virtual machine” software is inexpensive or free (such as Microsoft's Virtual PC), so you can easily keep an old system running (say, running SQL Server 7.0 and Windows NT 4.0) without requiring dedicated hardware.

Software Is Not Always The Answer

Usually, businesses want their software to match their processes, but sometimes it doesn't occur to them their processes might not be worth it. What they do may be old-fashioned, duplication of something else or simply unnecessary. This is particularly true in businesses old enough to have tasks which evolved before the personal computer era. A very simple example is archiving copies of invoices: virtually all accounting systems can reprint invoices on demand, so why would someone store boxes of paper piled to the ceiling? The answer is, because they started doing it in 1981 and never stopped.

It is into environments like this that businesses try to squeeze modern technology. For management looking for efficiencies, or trying to solve a problem, the temptation is to introduce a big computer system. But software and processes feed each other. If you have an inefficient process, fix the process. Don't just forcibly bolt-on a piece of software. If you spend a lot of time and money making your software work according to old methods, you lock in those old methods forever, perhaps replacing an inefficient manual process with an inefficient computerised process.

On the other hand, if you are happy with the efficiency and cost of an existing manual process, why introduce a layer of computerisation? Some things don't respond well to the sudden appearance of a computer. This is why you still buy so many yellow sticky-pads!

If you are deploying new software, use it as an opportunity to evolve the processes and reform the way the business works. It's an upheaval anyway, so why not make it a good upheaval? Software is often criticised for assuming idealised conditions that don't match real-world businesses, but it's not a bad thing to occasionally think of the “ideal” way of doing something.

Step back and look at the whole system. Managers can get very valuable insight by merely walking around the factory floor or helping with front-counter sales. Software can't tell you, for example, that you're losing customers because your aisles are impassable for people with baby strollers.

Of course, empirical data is important, and that's where software does a great job. But software is best at answering questions rather than help you work out what the questions are. Before you can improve the business, you might need to know what questions to ask. Thus: SOFTWARE IS NOT ALWAYS THE ANSWER.