Another ITIL hater...

My workplace sent me to an ITIL v3 foundation course, and I had 3 days of being taught the syllabus, followed by an exam. Technically, we had 2 and a half days of being taught, as the exam was on the afternoon of the 3rd day. Now, let me tell you why I hate ITIL.

I started out as an IT Technician. I'm a technical guy, and anyone who is technical knows that we have to follow a logical thought process to try and solve a problem. Let's say that a computer is blue-screening - well, we'll check the error code, check RAM etc etc We'll try to logically find the cause of the fault, then fix it. ITIL and the managers who take it (from what i've seen) use ITIL as a way of trying to prove they're intellectually superior and that the guys doing the technical work need to meet often ridiculous SLA's. It could even be argued that managers with ITIL don't see the hard work and knowledge a technical person requires as they just care about targets they need to meet, thus driving down/keeping down wages of techies.

Roadblocks

Fast forward a few years from my IT Technician days and I now work in the Digital Security field. Now, this place follows ITIL to the letter. Everything in the workplace is ITIL. I can tell you hands down it was the worst place i've ever had the misfortune to work in. Why? Because ITIL makes everything so damn slow. What do I mean? Let's take a CAB for example. I've got a firewall change I need to do. As anyone worth their salt knows, a firewall change should be done VERY quickly. A CAB slows down the process. It acts as a large roadblock. ITIL people will tell you "it's there to help" - but regardless of what it's "there for", it slows things down - which is bad...obviously.

Firstly, you have to get a hold of everybody on the CAB, which means emails get sent around, everyone has to accept and attend the calls at the right time. Things can get declined on CAB !!! Which means your firewall change wont be accepted immediately and hence, the roadblock.

Acronyms

My manager(s) would reel off the names of ITIL acronyms to all of the staff, knowing that the staff hadn't been trained on ITIL. The amount of acronyms within ITIL is ludicrous and serves as nothing more than an annoyance. If your manager emails you (because mine never had the decency to actually approach you) and says: "Can you look at the CMDBs and the SKMF? We'll have an ECAB if we need to because the SRM isn't around".... It's just a joke.

It says a lot that Axelos have a 70+ page pdf explaining such acronyms: https://www.axelos.com/Corporate/media/Files/Glossaries/ITIL_2011_Glossary_GB-v1-0.pdf

I could go on. All in all, this course/cert was the pits. Does anyone agree?? Or am I the only one who sees through the marketing BS/hype around this cert?

Find more posts tagged with

Comments

[Deleted User]

I hate ITIL myself. I had to do some online training for ITIL (foundations material) and I was bored as all get out. I wanted the torture to end. But at least I won't have to do it again (thank god).

scaredoftests

Agreed. Hated the foundation test (you have to contact like 3 organizations just to register for the test). Long winded questions that were so different from the practice tests.

N2IT

Never really bought it the framework. Had some decent pieces, but really went over the top in a lot of areas. I agree about a CAB not being realistic with a lot of other pieces.

It taught me somethings but overall it really just strengthened my service management vocabulary.

Iristheangel

Agreed. Some of the most ineffective managers I've seen in my career have been "ITIL certified" or "six sigma green/black belts." Thinking that buzzwords and acronyms magically improve your IT team or taking a "one size fits all" look at IT is a receipt for disaster. Without a doubt, I always see these managers move on from the disaster they created after they were canned by upper managers and put wonderful little plugs in their Linkedin such as "Transformed IT team at so-and-so-company to full ITIL-driven blah blah blah" and "highly successful implementation of a world-class enterprise technical service desk" etc etc etc.

As the great Tyler Durden once said, "Sticking feathers in your butt does not make you a chicken." Just like mindlessly following buzzwords and acronyms or getting certifications like CISSP (I speak as a CISSP holder), ITIL, Six Sigma, etc does not make you a manager.

TheFORCE

Technicians will always thinking like that, they are not trained to look at the big picture. They are not trained to understand how the process should be setup, how it should be structured, how it should be acted upon and how it show be resolved and documented. You are not at fault, you just got yourself in a position and an organization you don't want to follow. By your perspective everything looks slow, but on your managers perspective everything looks organized and documented and that is what you need in IT.

I was in the same boat as you, but the more I read about IT the more i see processes around me that could be improved by using the ITIL framework. You might only be seeing one side of things and not the big picture. Step back a bit and look at the entire picture, you will only benefit from it. I am currently trying to implement what i am learning from the ITIL book and i am getting such a push back from my organization, which is totally the opposite of what you are experiencing and it is so frustrating. You have no idea how it feels to work in a place where every does what they want to do, and that's not the way us IT people should approach things, there has to be an order of doing things.

N2IT

@ Iris, I always chuckle when I see an IT manager with Six Sigma. Six Sigma is fantastic in manufacturing when you are building high quality items, such as pace makers or other life critical devices. The 99.996% defect free rate makes sense. But in IT it's goofy, I understand downtime etc, but it's an overkill and it's expensive to maintain staff with a black belt. You could get another SENIOR network engineer for that cost.

@ Force that's called process and common sense. No one is saying process is not needed, but to go over the top such as ITIL is EXPENSIVE. This happen when ISO 9001 came out. The first year or so everybody went out and became compliant, but as time went on the finance teams started to realize it cost the company more money to manage this framework than it was worth.

ITIL is very similar to the PMP, in regards to how it extracts regular management concepts and put's their own spin on them

I don't hate ITIL but it's very overrated in a lot of areas.

UncleB

Hello Si20, I've responded to some of your points and taken a similar tone as yourself, but from a more experienced perspective. This isn't intended to be offensive but it looks like you are set in your ways so would benefit from some direct responses:

- "As anyone worth their salt knows, a firewall change should be done VERY quickly"
WRONG - if you need to make a change quickly then you either the project team responsible for the software requiring this change are failing to plan and notify in advance or you have an emergency situation (intrusion detection etc) and need an ECAB approval - normally only one person other than the requestor.

- "My manager(s) would reel off the names of ITIL acronyms to all of the staff, knowing that the staff hadn't been trained on ITIL"
If you (the average team member) knew you were expected to work in an environment that used all these acronyms and it just involved some reading up on them but don't do it, then you are a lazy employee. Do you expect the management to give you everything on a silver platter?

- "Let's take a CAB for example. It acts as a large roadblock."
It is supposed to act as the checks and balances needed to stop hotshot employees making changes without having them checked by other parties that may see where they are going to mess up royally by rushing in, say, a firewall change that will stop a key electronic payment system from communicating on the port they just shut down.

- "am I the only one who sees through the marketing BS/hype around this cert?"
You can only see if from your perspective as a minion doing your task. I've worked in the support engineer role, the manager role and service strategist role with ITIL and can honestly say that with some thought to its implementation, it is invaluable in producing a stable, effective and business oriented IT function.

The certification is proof that you have at least read the book and understand the terms, but if you are not willing to apply what you have learned then that is a different story. It filters the wheat from the chaff for selecting interview candidates so I can't imagine why anyone who may be seriously looking for an IT job would not do it.

I could have written the above in more flowery prose, but I thought you would appreciate the tone

thanks
Iain

Iristheangel

@UncleB: I see what you're saying. Definitely not against having processes - We in IT can't yolo every change by any means. I just think ITIL is overblown and approaching it as an "all or nothing" approach doesn't fit every enterprise, every culture, etc. My beef is against middle management who comes in and approaches it as such - I've seen a lot of good teams get siloed or bogged down because of it. That being said, nothing wrong with change management

I personally love being able to know what other teams are doing before I get alerts at 2AM and start freaking out.

Some of my posts lately on this forum have been my own gripes about seeing dysfunctional management and management through follow book-procedures, industry buzzwords, etc and the lack of dynamically being able to assess the real needs of the business and coming up with a strategy that fits it. That's not to say every ITIL-certified manager is horrible but I do see massive amounts of bad managers hide behind being ITIL-certified and thinking that following along with the book will make them stand out in any company. Often this is not the case. It's just like being a paper-cert when it comes to any of the technical certifications. Yes, a book may tell you to do XYZ, but as all of us as seen, production is very different

The_Expert

Iristheangel wrote: »

Just like mindlessly following buzzwords and acronyms or getting certifications like CISSP (I speak as a CISSP holder), ITIL, Six Sigma, etc does not make you a manager.

Amen, to that!

Being a good Manager is learned over time... not, by just having a piece of paper.

twodogs62

This thread is good reason to not just rush getting certain certifications.
some certifications need more work experience in the back end. Otherwise they are just paper.

some of what you are describing, I see as growing pains in the IT field.
things are getting more complicated rather than simpler.
what this requires is seeing the bigger picture, creating processes, yes this means documentation, just because you can make change doesn't mean you should make change, etc.... Unless you are the one that makes all changes. It teams are growing in size dealing with complex systems, thus there needs to be more coordinated effort for changes. Step on a coworkers work and break it, makes us all look bad.

i am am taking capm later this year. Not so much to be a project manager, but to communicate better with project managers and expectations of managers. I will get some tools and knowledge to help with some projects I will manage. I have now taken couple classes thru ed2go and cbtnuggets and my eyes are being opened.

bottom line, including myself is we technical people focus on technical items. We tend to not see big picture. We tend to not build our soft skills such as project management. In fact, I am reading tha technical people can be the worst project managers since they tend to micro manage. I think there needs to be balance too, but we are moving more into a world where a change is a change and needs to be documented, approved and coordinated so users are least impacted. We are becoming the electric company. Users don't care, they are just expecting their technology to work.

scaredoftests

I had to get the ITIL for a job I was at.

UncleB

Iristheangel wrote: »

I just think ITIL is overblown and approaching it as an "all or nothing" approach doesn't fit every enterprise, every culture, etc. My beef is against middle management who comes in and approaches it as such - I've seen a lot of good teams get siloed or bogged down because of it.

I'm with you there - this is largely a case with management in general as a lot of people end up in management because they can't cut it doing the actual work itself or can only justify their existance by trying to implement some process they read was good but without truly understanding how it relates to the situation they are using it in.

Think about the situation you would be in as an IT manager - you have to get the job done and you most likely lost track of the technology long ago so rely on your staff to tell you what is going on and make estimates on deliverables when they lack the experience to make an effective prediction. Add to this the fact you have to report to your own management above who are even more clueless but expect miracles while slashing budgets/headcounts to save costs. Add a big pinch of managing rotas / holiday cover / recruitment / annual reviews / problem staff / unhappy customers and the whole world of changing technological landscape every few years and there just aren't enough hours in the week to do all this well enough if you are not made of the "right stuff".

I'm sat in the middle management side at this point in time so have to take a very careful look about how to tailor ITIL to my companys requirements - I have a basic helpdesk function coming online now, change control has just gone live and the number of major system outages is steadily dropping and the users finding a much better experience in having their issues dealt with.

Finding the right balance to bring in and run ITIL while not being too rigid is essential, but sometimes I can see why the less experienced managers can use it as a stick to beat the staff with as it is one of the few things they think they know better than the IT staff.

As they say in my team, "you can't fix stupid". I just hope they are not referring to me in that...

thanks
Iain

si20

To add to my original post. I have been in IT for almost 8 years. I totally agree that we need processes in IT, of course we do, but ITIL is absolutely not the answer. ITIL presents itself as a framework not a standard and in my opinion, it's doesn't have a good foundation (no pun intended) to even be considered as a good framework.

I've seen countless people who hold ITIL certs downplay the role of technical guys and this infuriates me. Let me remind you (not just on this forum, but anyone reading this worldwide) - you need IT Technicians, Support, Security, Devs etc Without us, you can't exist. You need servers, support and infrastructure or your business will crumble (i'm talking about anything from local councils to large private companies).

I'm at a loss as to why ITIL is so popular. Sure, it's vendor neutral, but that doesn't mean that it's suitable for every business. During my ITIL training, we were given a scenario about a CAB. The person giving the lecture said that in a previous role, two of his IT team were on a CAB discussing a change they needed to perform. The discussion went like this:

Manager (also CAB leader): Ok, can you present your evidence for the change?
IT Tech: I need to upgrade the software because it comes with all sorts of benefits such as stability, better RAM handling and load distribution. The software will work with SSH once updated and allow RDP sessions via a built in protocol
Manager: Sorry, I don't understand exactly what the protocols are? I'm not a technical person. I'm going to have to decline on this occasion until I can see more evidence.
IT Tech: So what is the point of you leading the CAB if you don't understand technical information?
Manager: I don't need to understand tech-speak, I need strong evidence before I can let it go through CAB

And this scenario is one i've seen so many times. Why oh why do "managers" get the job if they don't do "tech speak" and aren't technical in any way, shape or form. Why?? It's like going to the doctors and describing you have had asthma and you need an inhaler, only for the doctor to say: "sorry, I don't really understand what asthma is, can you give me an alternative symptom?"

In my opinion - and i've said this for years - if you aren't technical, you shouldn't be managing IT. One of the worst managers i've ever seen in my entire career was a non-technical woman leading a security operations center (SOC). She just didn't get it. "Oh my god, oh my god. We've got a P1, we've got a DOS attack!!!". She didn't know about DDoS vs DOS or what this meant. I totally don't buy into anyone who says: "she doesn't need to know what a DDoS attack is" - she SHOULD have some kind of idea. How can you manage someone effectively if you don't understand the significance of the subject?

Another analogy: it's like getting an American basketball player to work as a football manager for Chelsea football club. Sooner or later, things WILL go pear shaped. And that's how I feel about ITIL. It's so non-technical and trying so hard to be clever with stupid acronyms, that it will fall flat on it's face. I sincerely hope ITIL becomes a thing of the past. It will ruin IT. Just my 2 cents.

UncleB wrote: »

Hello Si20, I've responded to some of your points and taken a similar tone as yourself, but from a more experienced perspective. This isn't intended to be offensive but it looks like you are set in your ways so would benefit from some direct responses:

- "As anyone worth their salt knows, a firewall change should be done VERY quickly"
WRONG - if you need to make a change quickly then you either the project team responsible for the software requiring this change are failing to plan and notify in advance or you have an emergency situation (intrusion detection etc) and need an ECAB approval - normally only one person other than the requestor.

In the ITIL world i'm wrong, but in the REAL world, i'm right. If you need to make a firewall change, you shouldn't be p*ssing about with project teams/managers/ECABS - it just needs doing/documenting (in my eyes).

- "My manager(s) would reel off the names of ITIL acronyms to all of the staff, knowing that the staff hadn't been trained on ITIL"
If you (the average team member) knew you were expected to work in an environment that used all these acronyms and it just involved some reading up on them but don't do it, then you are a lazy employee. Do you expect the management to give you everything on a silver platter?

Again - you're wrong because this is your ITIL way of thinking. You think i'm a lazy employee because i've been hired by someone with an ITIL cert, who KNOWS I don't have an ITIL cert? Surely they should train me if it's required.

- "Let's take a CAB for example. It acts as a large roadblock."
It is supposed to act as the checks and balances needed to stop hotshot employees making changes without having them checked by other parties that may see where they are going to mess up royally by rushing in, say, a firewall change that will stop a key electronic payment system from communicating on the port they just shut down.

I understand what the CAB is for, but it's a roadblock pure and simple. If you think you have hotshot employees, then that says more about your hiring skills than it does about anything else.

- "am I the only one who sees through the marketing BS/hype around this cert?"
You can only see if from your perspective as a minion doing your task. I've worked in the support engineer role, the manager role and service strategist role with ITIL and can honestly say that with some thought to its implementation, it is invaluable in producing a stable, effective and business oriented IT function.

I disagree completely. Staff turnover at my old job was insane. I was training 2 different people per month due to the amount that were leaving due to god-awful processes that taken forever to remediate issues and poor management.

The certification is proof that you have at least read the book and understand the terms, but if you are not willing to apply what you have learned then that is a different story. It filters the wheat from the chaff for selecting interview candidates so I can't imagine why anyone who may be seriously looking for an IT job would not do it.

And this is another problem. Unless other companies you deal with use ITIL, you've hit another roadblock. I'm sorry, I just can't see how anyone thinks ITIL is anything more than marketing fluff mixed in with a bit of common sense (e.g documentation).

I could have written the above in more flowery prose, but I thought you would appreciate the tone

thanks
Iain

eSenpai

Interesting thread...and going to go against the tide here.
As someone who is been through ALL of the classes listed in this thread plus TOGAF, COBIT, Prince2, ISO 2700x and a few others what I can say as "that guy" is many here are confusing an ITIL manager and ITIL processes with bad managers and bad processes in general. I submit that if you remove ITIL from all of those you will still have bad managers and slow processes. Saying that ITIL made them that way is overstating the issues at hand. That's not to say that ITIL, Six Sigma, and others don't have applicability issues because they do but a lot of the sounding off here sounds like there are bad people making bad management decisions. The frameworks don't make those decisions. People do. If those people are justifying their decisions by saying "ITIL (or X) made me do it." then that kind of tells you what kind of person they are to begin with. Plus, almost all of the frameworks both allow and encourage you to choose only those parts which work best with your organization. That of course implies that one FIRST has the knowledge to understand which are applicable but sadly many do not have the actual experience to do that.

I do totally agree that the trend to hire non-IT people into IT management positions or IT oversight positions is a constant corporate failing that I have never understood. You wouldn't hire a Chemical Engineer to be head of sales without ever having done sales but people feel absolutely comfortable hiring a MBA or "Well she/he is great manager; they just don't know IT." to be over IT processes even though that MBA/person has NEVER worked hands-on within IT.

[Quick side note: Six Sigma is actually excellent for streamlining Support Desk processes and getting to great customer satisfaction if one has the ability to glean the metrics needed. However, a never-ending sigma project is simply not the answer.]

UncleB

Hello si20, I've replied to a few more points from your last post

- "you need IT Technicians, Support, Security, Devs etc Without us, you can't exist."
Actually you are eminently dispensible. The role you perform can be replaced in a few days with a contractor so long as your systems are documented and processes clearly defined and followed. THIS is one of the reasons managers push for documentation and process - so they can't be help to ransom by techies with ideas above their station. I've recently had the misfortune to have to push through just such a change to wipe out an entire team of 8 and switch to using 3rd party specialists and contract staff while new permies were recruited who were not so militant. It was painful for me (I was directed to do it) on many levels but the business didn't even notice.

- "I'm at a loss as to why ITIL is so popular."
Because if it is tailored properly it works (this is one of its core principles). The tailoring part is where too many managers go wrong because they don't understand it well enough. I've used it very successfully in banks around the world, the civil service, the education sector and in a large food manufacuring business so can testify to this.

- "Manager (also CAB leader): Ok, can you present your evidence for the change?"
The person presenting the change has to see the bigger picture of what their change will mean - to say it will give better RAM handling and load distribution is meaningless to the business - you have to explain the benefits of this (eg speeds up traffic through the firewall resulting in faster web browsing and file transfers plus allows more people to use the firewall at once without it slowing down their internet experience).
This sort of CAB discussion is classic techie mentality that will always lead to frustration on both sides - the manager is too far removed from the technology to understand it in the way the techie does but the techie cannot see out the silo of technology they work in - the weakest link (techie) has to be the one to change unfortunately since it isn't practical for the manager to gain the breadth of technical knowledge to deal with all types of changes they have to process.

- "Why oh why do "managers" get the job if they don't do "tech speak""
Most get it as a way to move up the ladder, earn more than the techies and get an easier life where they don't have to keep pace with the constantly changing world of technology. Some like the power and some just float up to the role because they are so bad at being techies that their management promote them out of harms way.
I like to think I chose the career in order to make a positive difference and to make the most of my 27 years experience as techie and technical team leader (with occasional stints as manager for a few years here and there), most of it contracting and having to constantly prove my ability to stay in the contract. After going through a number of "recruit my successor" hiring sessions in my last few roles when I wanted to move on, there are very few other wannabe managers out there with a similar attitude.

- "if you aren't technical, you shouldn't be managing IT."
I have to disagree there. One of the best managers I ever had wasn't technical and made the team explain what we wanted to do in laymans terms to make sure we truly understood it ourselves, plus with my colleagues present so they acted as the checks and balances to my choice of technology solution/action. I probably learned more in that year than in any year since including how to translate some of the trickiest technology subtleties to users who barely know how to login.
The success of the manager is down to their ability to manage and to the team to build a working relationship that can get the information flow right.

- "If you need to make a firewall change, you shouldn't be p*ssing about with project teams/managers/ECABS - it just needs doing/documenting (in my eyes)."
I strongly disagree - just doing things without these checks has caused more outages than any bugs / attacks ever has. It also relies on you then updating the documentation and, lets face it, it is low on most techies priority list once the job is done.

- "Surely they should train me if it's required. "
So long as they make the training available to you then you need to make sure you make the time to learn, preferrably in your working hours. If you can do firewall changes then understanding ITIL is a walk in the park. If there is no training available then you need to reflect this in your performance reviews and say you feel disadvantaged - the threat of this going on the record when it should be done will get it sorted out pretty quickly.
I believe in self development and won't rely on someone else to train me - get the books through work (or download them if you are less scrupulous) and learn - ask the company to pay for the exam and you are part way to a pay rise or a new job depending on what you want.

- "If you think you have hotshot employees, then that says more about your hiring skills than it does about anything else."
My experience is that it is the hotshot employees who think the CAB is a roadblock because they don't believe it has value - because they can't see the bigger picture of the protection it offers to production systems. These sort of employees are quickly "performance managed" of of my team and normally out of the company as they know the rules and if they won't follow them then they should no be there.

- "Unless other companies you deal with use ITIL, you've hit another roadblock."
Not really a problem as it comes down to how ITIL is tailored to your company. You don't need to do more than you require, so something like the helpdesk function, change control, some CSI and a smattering of other aspects are enough to add a load of value. Going too far without the need or ability is a sign of poor management and is likely to cause the sort of high staff turnover in extreme situations, although this is often symptomatic of a deeper problem in the department or company.

I've only worked in one company that had ITIL just right and this was after we brought in ISO 20,000 (the service provider standard) - our systems were stable and efficient and everyone was trained and then had their part clearly explained by the guy in charge of the ISO 20k work to make sure they understood why and how everything was done. He was a good manager and charismatic so made a big difference in makeing people want to do their part.
This is the sort or person I aspire to be like although the company was relatively quiet and had a high ratio of IT staff to other employees, so was a bit of a nirvana for any IT team.

The frustrations you have experienced with ITIL seem to stem from a combination of poor customisation, dogmatic adherence to principles and generally poor management, none of which is the fault of ITIL.

Good luck with the trials and tribulations of the daily work.

thanks
Iain

Claire Agutter

What a great thread

Some strong arguments on both sides. si20, one of the bits of ITIL that is often missed or not given enough priority is continual service improvement. Does your organisation give you a way to provide constructive feedback that might improve how things are working?

twodogs62

Liked uncleb response.
Lots of good comments here.
points I see are balance and also self development.
don't wait for others to train you.
consider any training as professional growth.

si20

UncleB wrote: »

Hello si20, I've replied to a few more points from your last post - "you need IT Technicians, Support, Security, Devs etc Without us, you can't exist." Actually you are eminently dispensible. The role you perform can be replaced in a few days with a contractor so long as your systems are documented and processes clearly defined and followed. THIS is one of the reasons managers push for documentation and process - so they can't be help to ransom by techies with ideas above their station. I've recently had the misfortune to have to push through just such a change to wipe out an entire team of 8 and switch to using 3rd party specialists and contract staff while new permies were recruited who were not so militant. It was painful for me (I was directed to do it) on many levels but the business didn't even notice.

Your logic, or ITIL's logic is why IT is going to end up spontaneously combusting. This concept is so flawed I cannot even begin to describe it, but i'll try. If you think your IT team(s) is/are dispensible, you're causing the problem. This has proved my previous point - ITIL adoptors are pushing down the ideas/salary of IT teams because it gives this utopian standpoint whereby managers think they're "above and beyond" IT techies and that they're easily replaceable.

My previous workplace (who used ITIL right down to the letter) was an absolutely horrible place to work - and no offence, but it sounds like your organisation is also a horrific place to work too. Knowing that you're going to work, going to have your decisions and ideas blocked, having changes CAB'd, which increases the length of time before they become actionable is soul destroying - and knowing that your seniors are more than willing to fire you and replace you with a 3rd party - that is unimaginable, absolutely unimaginable. You begin to feel like a robot. You're undervalued, undermined on a consistant basis and this leads to job dis-satisfaction. You say you don't want "to be held ransom by techies with ideas above their station" - I find this is extremely offensive to techies. Because we're a techie, our ideas aren't as good as yours? Our ideas cannot possibly be better than yours?? Treating techies like this is just asking for trouble.

You got rid of a team of 8, and got 3rd party specialists - but they will hold you to ransom!!! They will say: "pay us X amount of cash" and you'll have no choice, because you fired your internal team. Sure, you could go to ANOTHER specialist team but you'll be in the same boat. And even if you somehow manage to get these specialists at a cheaper price than other offerings, I can assure you that they wont be "specialists". If you pay peanuts, you get monkeys. I worked as a Security Analyst for a very large corporation. They hire graduates from University for peanuts - none of them have the foggiest what they're doing and they have extremely slim knowledge of security, but they are advertised to clients as being "specialists". If the business didn't notice the difference between an internal and external team, the business MUST be doing something wrong. Internal teams are almost always favoured over 3rd party teams as it's often cheaper and the staff get to know the systems better than external teams.

Claire Agutter wrote: »

What a great thread Some strong arguments on both sides. si20, one of the bits of ITIL that is often missed or not given enough priority is continual service improvement. Does your organisation give you a way to provide constructive feedback that might improve how things are working?

I can actually agree with the CSI described in ITIL (yes, i'm not completely anti-ITIL! ha!) but the manager was reluctant to take ideas and if she did, they were often my ideas but pushed out from her without credditing me - which I admit is a problem with that manager more than ITIL. I've since left that organisation and would never dream of going back.

UncleB

si20 wrote: »

ITIL adoptors are pushing down the ideas/salary of IT teams because it gives this utopian standpoint whereby managers think they're "above and beyond" IT techies and that they're easily replaceable.

There is no good reason why IT should not be a service in the same way finance an HR are - a defined set of processes and procedures with KPIs and SLAs to measure it which can be handled by any organisation who have disciplined staff and access to specialist knowledge. As a techie I want my salary to be high of course, but the reality is there is simply no need when there are plenty of companies (especially in India) where a well defined contract with the above componenets will not get the job done adequately at a reduction of cost and risk to the people paying the bills.

si20 wrote: »

it sounds like your organisation is also a horrific place to work too. ... and knowing that your seniors are more than willing to fire you and replace you with a 3rd party - that is unimaginable, absolutely unimaginable. You begin to feel like a robot. You're undervalued, undermined on a consistant basis and this leads to job dis-satisfaction.

I didn't choose to let the staff go - that idea was a directive from above from the bill payers who wanted a system brought in like you describe. There are droves of technicians out there wanting jobs even in such an environment and some thrive in the comfort of structure and defined expectations. Nothing is unreasonable and I routinely perform all the duties for a day a week that I expect my staff to do, if for no other reason than to feel any pain they feel and work to improve it.

si20 wrote: »

You got rid of a team of 8, and got 3rd party specialists - but they will hold you to ransom!!!

The vendors are normally the hardware or software suppliers so if they try to hold us to ransom then they will find the contract moved quickly away from them and our legal specialists taking them to court for breach of contract. These are mainstream products so finding even a 3rd party will not be hard, or at worst we can bring the skills inhouse if need be.

I have a very frank and open discussion with the 3rd parties when drawing up the contracts and tell them to expect heavy penalties (drawn into the contract) in the event of breaches - this tends to keep them focussed on doing what they are paid for.

When you think about the general direction that IT is heading in (cloud based systems replacing local hardware and skill sets) and most things moving to subscription based service, there is less and less need for technicians locally, so unless you are a developer adding value to a business then the future is bleak. Yes there is going to be local 1st line support needed but 3rd line support will eventually just fade away into a few, highly contested roles with low salaries. To me the writing has been on he wall for years (since AWS started replacing servers in their droves in a company I worked in, and with Microsoft Azure / Office 365 it is just gathering momentum.

To my mind it is better to see what is happening and make the most of it rather then bemoan the changes and feel a victim.

I hope you find a role that works out for you.

thanks
Iain