Two Ideas for IT Sanity

I was thinking today that it is crazy that most companies employ people and let them use computers for most things but that very few insist on any formal qualifications to prove you know what you're doing. To think of the number of times something is saved in the wrong format, things that should take minutes take hours because somebody doesn't know the quick way and generally computers that should save loads of time take longer than pen or paper. I reckon any serious company should:
1) Insist on a formal qualification for the level of IT work required in a job (i.e. basic Office skills, Basic Database Operation or whatever)
2) It should be rammed home that if something is repetative and time consuming that it can be done faster using the right technology (even a few hundred pounds is cheaper than days of someones time).
One example of IT indeptness was when I used to work for a company where someone had to send out loads of letters to Doctors whose addresses were in a large book and that had to be looked up manually and typed into a template letter (100s of letters a week). I asked the person whether they had the details on disk and showed them how to mail merge. Hey presto, a 1 or 2 minute job now took 5 seconds.
Somebody told me the other day that somebody measured the productivity of a company before and after computers were introduced (over a 20 year period) and that the productivity was identical. That figures. People buy the wrong kit and don't know how to use it. To all you clever IT managers out there, work out how to use your stuff properly and you might save £1,000s!

How to get quality in Important Systems

One of my biggest gripes about British industry is our seeming lack of concern for quality and at least our inability to understand the basics. If you do not understand quality, why are you surprised when things get lost/stolen/broken?
Well here are some tips about quality, some baseline assumptions which you need to consider when planning a quality policy or just plain old development processes.

1. People make mistakes. It doesn't matter how experienced they are. People don't consider all possible uses and abuses of a system so make sure you have a way of checking work. This doesn't guarantee lack of mistakes but reduces the likelihood.
2. If you reduce the likelihood of problems over a whole range of 'attack surfaces' then you will massively reduce the likelihood of problems. For instance, if you have a web site, it is not enough to lock-down the web page itself. You need to lock down every level from the web site right down to the hardware running it. This allows someone to break the front end but still not get anything useful.
3. You cannot predict the future. Just because something works now, does not mean it won't be broken in the future by someone more determined/able/with faster computers.
4. Nobody is expert in everything. Get a range of people with different expertise to look at all the different facets.
5. Don't forgo testing. People who develop products rarely use them in the way that an end user would. They find problems that an end user wouldn't and miss things that would easily be found by basic testing in a real-life scenario.
6. If something goes wrong in the finished product analyse what happened and work out how you can change things to avoid it happening again. For instance, was it caused by someone too junior making the final decision, you might decide to run all ideas past someone more senior but ask honestly whether the problem would have been avoided rather than trying to blame people.
7. Listen to the people at the bottom of the pecking order. If they have ideas to improve things, honestly find out whether they would and implement them. Don't have that "manager knows best" mentality because they don't!
8. Spend time looking around for what other people do/use in similar cicumstances. Perhaps you need some training/tools/people.
9. You might have to spend money! Don't expect world class products on a garden shed budget.
10. Don't make loads of big changes. Quality should be incremental. Start with a decent foundation and then make small changes over time so that quality always increases. Identify redundant parts of the process and get rid of them.