On the one hand I hate trite statements of 'values' but on the other hand, when something goes wrong in our IT team it is usually because someone has broken one of the 'rules' - or didn't know the 'rule' in the first place. About two years ago I tried to write them down as I was fed up with the same mistakes getting made over and over again.

This led to a howl of protest from some of my colleagues, who felt that this was imposing a culture. Others thought it was a good idea - a baseline of expected behaviours. The whole thing imploded into a sort of hippies v control freaks debate. I decided the whole thing was too divisive and quietly let it drop.

Two years on. And the same mistakes still get made. And I'm still not happy that the culture is right. Time to dust this off.

When I looked at this two years ago I found an excellent article in CIO magazine - in particular a list by Ron Bonig of George Washington University. "As long as you operate in these parameters, you will get your job done," he says. "We can correct any honest mistake." I completely agree.

Ron Bonig's Golden Rules

Rule 1 Production is job number one.

Rule 2 The first part of job number one is to "protect the data." Backups are sacred. Even scheduled production can be interrupted to get a clean backup.

Rule 3 Nothing I say regarding deadlines, projects or special initiatives should ever be construed as permission to deviate from Rule 1 and Rule 2.

Rule 4 Standards and procedures are your safety net. If you follow them, you can be virtually guaranteed that no mistake you make will cause a disaster (the procedures include peer review, testing and validation).

Rule 5 If you don't document it, it didn't happen. Keep it online and in several places. If you write it down on paper, it's obsolete before the ink is dry! (Especially for documentation, configurations.)

Rule 6 The most important part of the plan is the back-out strategy. If it all turns to "soup," you can get back to a steady state if you have planned it.

Rule 7 There is no such thing as an inconsequential change.

Rule 8 Never say no to a user--just put a price tag on the yes.

Rule 9 Nobody is indispensable...but all the systems administrators are forbidden to cross the street at the same time.

Rule 10 To borrow from Mark Twain: "Put all your eggs in one basket, then guard that basket!"

Rule 11 And to also paraphrase von Clausewitz: "No plan survives intact the first contact with the users."

Rule 12 You can put the square peg into the round hole, but you have to use a big hammer. It is easier to recruit and hire for the skills you want in the first place.

Rule 13 It's only money. If it is critical, we'll have a bake sale.

I've only got two to add to this list:

1 - If you agree to do something by a given date either do it by then or tell whoever you didn't get it done.

2 - The Rule of 20's for projects - mentioned in a recent post