11 Things You've Heard Before About Systems Management But Need to Hear Again
by Robert Bradt
Like the old joke about the weather, everybody talks about systems management, but nobody does anything about it. That isn't strictly true, I guess, most organisations do something; it just that it's usually not enough. However, before I tell you what you've heard before and need to hear again, I should tell you what I mean when I use the phrase "systems management".
Systems management means devising ways to use the computing resources of an organisation in the most efficient way possible.
I know what you are saying: "hey, do you think we went out and spent umpteen million on hardware and software without knowing how to use it?" For most organisations, that's not quite what I am saying, but it's close.
You see, the key phrase in my definition is "computing resources". I did not say "hardware and software", because there is more to your information systems environment than the code and the iron. People, and the processes and procedures they follow, are resources too. If your organisation does not use them effectively, then spending umpteen million on hardware and software is not going to result in efficiency. Which leads to the 11 things you've heard before about systems management but need to hear again.
- Machines cost money.
- Fashion is fickle.
- Change is a Pain.
- Miracles seldom occur.
- Fix your procedures, you fix your problems.
- A good procedure is worth a thousand words ('cause it usually isn't that long).
- Good people are good value.
- Chickens do not have lips.
- Users are people too.
- Manage the people and the machines will take care of themselves.
- Have fun.
1. Machines cost money.
You would think this point would be obvious, but it is amazing how often we forget it. You can buy the fanciest hardware around, the whizziest, fastest, coolest stuff available, and it won't do anything until you tell it to. A water-cooled, nitrogen-powered, bio-technic, super-charged WhizzBang 6000 artificially intelligent processor does not order pizza until you tell it want you want on it - double cheese, anchovies, or what?
Invest all you want in such technology, but know why you are buying it, what it will be used for, how it will be used, who is paying for it, what it's useful lifespan will be, and all those other bean-counter, hard-headed questions that MBA's are supposed to ask. If you don't have answers, don't buy it.
2. Fashion is fickle.
Technology today is as fashion-conscious as a designer's walk in Paris or Milan. You'd think Vogue was required reading, the way some organisations decide technological issues. RISC is hot, CISC is not. Mainframes were in, then out, now in again. AI was, was not, sort of is. Don't change your hardware just because it isn't fashionable any more. If a Cobol program running on a dinosaur-powered mainframe using card-punch readers is doing the job, ask yourself why you should replace it. There may well be good reasons, like lack of vendor support, or of support people within your organisation, but know what those reasons are before you make your decision.
There are lot of organisations out there literally throwing away PCs with 8088 processors, replacing them with 486-powered behemoths, just so people can e-mail each other and write the occasional memo. Think about why you are doing something - remember Machines cost money.
3. Change is a Pain
Whenever we make any kind of alteration, whether through the introduction of new technology, or new people, we are making changes. People don't like changes, it upsets the grand scheme of the universe. People like nice stable, steady-as-she-goes kind of environments, although sometimes they see chaos as stability, if it's all they've ever known. People can get fixated on putting out fires, to the point of not asking why so many are occurring in the first place. It is comforting to be needed, and you need fire-fighters, so if someone comes along and changes the way fires are put out, then noses will be out of joint.
Since we can't change the fact that things change, we have to learn to live with it. One way to do that is to proceduralise it, making the changes fit into a framework that will offer some stability to the fire-fighters in your organisation. You can still do a lot of change this way, it's just scheduled, approved, and implemented according to a plan. This stability framework gives everyone something to hold onto, and is, in fact, a procedure. More on procedures later.
4. Miracles seldom occur.
A lot of times, we know we have a problem, some issue that needs to be resolved. However, we have to remember, no matter how much we might wish that the Computing Gods will wave their hands and make our problems disappear, it ain't going to happen. Problems get fixed because people fix them. People fix them because they have good procedures to follow. Which leads to the next point.
5. Fix your procedures, you fix your problems.
People fix problems, not the other way around. People know about problems because they have good processes and procedures to follow. People prevent problems from ever occurring because they have even better processes and procedures to follow. The sign of a really good problem management procedure is a lack of problem records, because they were prevented from happening in the first place. A good change management procedure is merely another aspect of a good problem management procedure, because managing changes well will head off a lot of problems. Conversely, a good problem management procedure will eliminate the need to make a lot of changes.
6. A good procedure is worth a thousand words ('cause it usually isn't that long).
Since we remember that if we Fix our Procedures, the Problems Will Take Care of Themselves , then it follows that we should spend time working on them. You have to invest time in procedural-definition tasks, so you can get the payoff of smooth operation later on. Defining your procedures from scratch is sometimes easier than starting with something and "fine-tuning" it. People will have attachments to the old way of doing things, because that it is what they are used to, and Change is a Pain. Therefore, whenever you review your procedures, start with a clean slate. Look at it from first-principles every time, to make sure those haven't changed. That way, as your people, your customers, and your technology changes, you can stay on top of things.
To implement a procedure effectively, you must have buy-in from the people who will be asked to follow it. Getting buy-in means two things - each person must feel they are getting something out of it, and they must feel they put something into it. The simplest way to achieve both aims is to hold a workshop meeting of the key players impacted by the procedure - operations, the customers, the programmers, the Help Desk, and whoever else might be involved. Take them off-site to a neutral place; perhaps a hotel meeting room, a convention centre, a vendor- supplied meeting room, the company board-room, or anywhere that is not home turf.
Once off-site, appoint a facilitator. This person can be part of the group, but it is better if it is a neutral third-party, like someone from a totally different part of the organisation, or a consultant. The facilitator leads the discussion, seeking answers to key questions like:
- What is the IS organisation's overall goal?
- How does this procedure contribute toward that goal?
- Who are the customers of this procedure?
- Who are the vendors/supporters of this procedure?
- What are the deliverables from the procedure?
- What are the mechanisms for achieving these deliverables?
For example, the overall goal of the IS organisation might be to deliver software applications in support of a banking operation. The procedure, such as a problem management procedure, is aimed at preventing outages with those software applications. The procedure's customers are the tellers in the bank branches. Operations, Help Desk, Programming, and Network Support are the vendors and suppliers. The deliverables are problem analysis and availability reports. These are achieved by describing problems when they occur and recording the times and actions associated with the resolution of the problem.
The questions above are the keys, and should let you frame a procedure in less than one thousand words. Other questions may occur to you, and that's fine, but answering these should get you started. Reviewing these answers when you review your procedure will make sure your original assumptions are still valid. You should review your procedures annually, even semi-annually if there's lots of new technology or people being introduced. These workshops can be run in a day, and the resulting procedure can be reviewed and signed off within a week. That's not much investment necessary for a smooth operation.
7. Good people are good value.
A good person, skilled, experienced, full of common sense instead of foolish pride, is worth more than any technology. You can always buy technology because it lies around on shelves and in warehouses. Good people don't grow on trees, aren't manufactured, and can't be cloned in a test-tube. You can't buy good people. The smartest investment an organisation can make is to identify its good people and reward them.
Actually, come to think about it, that is the second smartest investment an organisation can make. The smartest is to identify its not- so-good people and do something about them. A really smart organisation makes every effort to train, encourage, and otherwise improve these not- so-good people before it lets them go, which it does only if it has to. Being seen as a caring organisation is a good thing, because it makes everyone, including the good people, work even harder.
Smart organisations and managers remember that rewards are not always monetary. They can be as simple as a pat on the back. My wife once had a manager who used to bring her tea and muffins when all hell was breaking loose. She worked harder for him than she would have had he merely given her a raise, or worse, ignored her work. By getting to know her well enough to realise that she liked tea and muffins, and to recognise when she was in need of encouragement, he demonstrated to her that he appreciated her as a person, not merely as a unit of production. Monetary rewards are nice, and they pay the bills, but they are impersonal. If you can't say thank you in person, it looses a lot of the impact.
8. Chickens do not have lips.
Vendors often tell you that your problems will be solved if you just buy their whizz-bang technology. They say things that imply that Miracles Often Occur. However, as any 5-year old can tell you, "Chickens do not have lips."
If a vendor analyses your operations and recommends that you buy their technology, you can bet that they will tell that this technology will solve your problems. However, a whizz-bang tool used in a pea-brained process will result in a pea-brained product produced in a whizz-bang way.
Most technology vendors, to be fair, are only trying to make a living, and most times, their technology is quality stuff that does a good job. But as we already said, Machines Cost Money, and Miracles Seldom Occur. Therefore, you should never buy technology just because the vendor says you should. You have to know why you are doing it, and you have to fix the process problems before you do it.
9. Users are your friends.
There are a lot of organisations out there where the word "user" is a four-letter word. "If it weren't for these darned users !#&*@$)*&!, we could get our work done". Sorry, users are people too. If you don't treat the people who use your technology like the human beings and customers that they are, you are in trouble.
All that whizz-bang technology, remember, is there to do something. If the people who use that technology to do that something are not satisfied, you have wasted your time. If you want to make sure that you get value for money, because Machines Cost Money , then you have to make sure the people using the technology you support are happy. In order to be happy, they have to get what they want - you have to ask them what they want, and deliver it on time.
Make it a practise in your organisation to outlaw the word "user". These are not drug addicts, they are your customers. An information systems group exists within any organisation because people need those services, but remember that they don't have to get them from you. Does the phrase "out-sourcing" have an ominous ring to it?
If you treat the people to whom you are supplying information technology and services like the customers they are, then you will do things like ask them what they want. You will not become exasperated when they say things like "I'm not sure", or "can you put this in living 3-D colour graphics (yesterday)". Part of the service you must deliver is helping customers define what they want. Just don't get caught up in the vendor game, or you might finding yourself saying Chickens Have Lips, or Miracles Often Occur.
10. Manage the people and the machines will take care of themselves.
Ok, so you have a bunch of good people, and you treat everyone well, nurturing the not-so-goods, and rewarding the good with kind words, gentle thoughts, and dollops of money. Now what.
What you do is you manage things. Management means setting priorities and goals. It means planning how to achieve them. It means guiding the people, because then the machines will take care of themselves. If you can justify buying technology that manages itself or other technology, like a LAN management tool that automatically re- routes traffic to optimise demand, then great, go ahead and do it. Installing that LAN management tool, however, will require planning and project management. If you mess that up, your tool will never work.
11. Have fun.
Never miss an opportunity to have fun. If you can't enjoy your job, you won't be enthusiastic, and if you aren't enthusiastic, you won't be efficient. Lighten up - you work with information systems, it's not like you're curing cancer, or ending world hunger. If you want to be serious, go study philosophy or get involved with radical politics.
The rest of us realise that we are here to do what we can as much as we can, and we are smart enough to take a break when we get too tired or frazzled to think straight. There is nothing dumber than working 27 hours in a day just to prove you can do it. A manager that expects you to arrive early, stay late, and work weekends, without giving you clear goals and tasks, is not a person you want to work for. Have fun!
Okay, so now you have been told 11 Things You've Heard Before About Systems Management But Needed to Hear Again. Sometimes it's the obvious that we overlook. None of the stuff I said above is new or earth- shaking. I've heard it myself from other people. It's just that it's such basic common-sense kind of stuff that we tend to pay lip-service to it and not really believe it. All I am asking from you, kind reader, is to think about it.
Copyright © 1994 infothink ltd. All rights reserved.
Used by Permission.