![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Beez-nez rant
Jan. 23rd, 2004 01:52 amDo you ever enter a room and are suddenly overcome with the realization that you're in a room with soulless drones?
I had that experience today. I went lunch time meeting that featured a prominent motivational speaker who was speaking of the future of service desks(help desks). He was pretty full of himself, and I don't find credence in a lot of what he says. I liken business institutes like these to large circle jerk sessions. People are networking, but not a whole lot of thinking is going on.
He is supposed to be witty, but frankly, using surfer dude accents and calling the folks in the room either geeks or suits is just sub standard. Also, he thought he could somehow appease the audience by blaming the project and development arm of IT for the service desks problems.
Frankly, that's not the only source of the problem. And if I had a chance to talk to this speaker, I would tell him:
"Look, dickbag. You need to figure out what's important to you. If it's on-time and on budget, don't be surprised to find the problems after implementation. Don't blame IT for being pressured to do way too much at once, and expect them to deliver a perfect project on time. You want perfection? Pay for it. Hire more people. You either pay for more people and get it done right, or pay later in lost productiving and resentment. But don't act like a company can do it all, because it cannot or refuses to do so."
No I know there is room for waste. But when you're doing new system development, even the best of test plans cannot live up to a real live implementation involving hundreds or thousands of users. Sure it's possible, but it is rare.
Furthermore, this highly paid, professional speaker ran an hour over time, he skipped slides, and bragged about having too much material in his presentation. Anyone who publicly speaks knows that's pathetic. It was certainly good food for thought, however.
ITIL is the latest craze in IT. It's been in Europe and elsewhere for probably 5-10 years. It covers process best practices in seven areas, including project management, problem management, end-user management, security management. I'll have to look into it more, but it strikes me as the same shit, different day.
Don't get me wrong, processes are great. But that's not the hard part. We've got the process down pat. It's implementation that sucks. And then there's developping the wrong process for the problem.
A lot of these processes seem to have the same type of components. They are cyclical in nature and seem to have roughly these phases that can be broken up or consolidated as needed in order to appear new and exciting for the fad whores of the business world.
1. Get your shit together (gather requirements)
2. Document the shit.
3. Determine scope of shit
4. Develop shit
5. Test shit
6. Communicate shit.
7. Roll the shit out.
8. Gain feedback from users to determine if it is good shit, and reengineer through the phases as needed.
Of course, if your requirements are shitty, the project is doomed for failure, or merely a stressful few months to stabilize the work environment.
So, we all know what we need to do. Why is it we need new books and expensive training classes to tell us a not so subtle variation of the same old process? Because we prefer to piss training dollars down the drain so we can get out of the office?
Of course, all this is at a simple level. I could go on, but I'm sleepy and must rest.
I had that experience today. I went lunch time meeting that featured a prominent motivational speaker who was speaking of the future of service desks(help desks). He was pretty full of himself, and I don't find credence in a lot of what he says. I liken business institutes like these to large circle jerk sessions. People are networking, but not a whole lot of thinking is going on.
He is supposed to be witty, but frankly, using surfer dude accents and calling the folks in the room either geeks or suits is just sub standard. Also, he thought he could somehow appease the audience by blaming the project and development arm of IT for the service desks problems.
Frankly, that's not the only source of the problem. And if I had a chance to talk to this speaker, I would tell him:
"Look, dickbag. You need to figure out what's important to you. If it's on-time and on budget, don't be surprised to find the problems after implementation. Don't blame IT for being pressured to do way too much at once, and expect them to deliver a perfect project on time. You want perfection? Pay for it. Hire more people. You either pay for more people and get it done right, or pay later in lost productiving and resentment. But don't act like a company can do it all, because it cannot or refuses to do so."
No I know there is room for waste. But when you're doing new system development, even the best of test plans cannot live up to a real live implementation involving hundreds or thousands of users. Sure it's possible, but it is rare.
Furthermore, this highly paid, professional speaker ran an hour over time, he skipped slides, and bragged about having too much material in his presentation. Anyone who publicly speaks knows that's pathetic. It was certainly good food for thought, however.
ITIL is the latest craze in IT. It's been in Europe and elsewhere for probably 5-10 years. It covers process best practices in seven areas, including project management, problem management, end-user management, security management. I'll have to look into it more, but it strikes me as the same shit, different day.
Don't get me wrong, processes are great. But that's not the hard part. We've got the process down pat. It's implementation that sucks. And then there's developping the wrong process for the problem.
A lot of these processes seem to have the same type of components. They are cyclical in nature and seem to have roughly these phases that can be broken up or consolidated as needed in order to appear new and exciting for the fad whores of the business world.
1. Get your shit together (gather requirements)
2. Document the shit.
3. Determine scope of shit
4. Develop shit
5. Test shit
6. Communicate shit.
7. Roll the shit out.
8. Gain feedback from users to determine if it is good shit, and reengineer through the phases as needed.
Of course, if your requirements are shitty, the project is doomed for failure, or merely a stressful few months to stabilize the work environment.
So, we all know what we need to do. Why is it we need new books and expensive training classes to tell us a not so subtle variation of the same old process? Because we prefer to piss training dollars down the drain so we can get out of the office?
Of course, all this is at a simple level. I could go on, but I'm sleepy and must rest.
