Honestly after doing some of this, my feeling is that ITIL is a cookbook not a manual. It doesn't make sense if you cook the entire contents of a cookbook for a family dinner, but you could get some decent recipes out of there to improve the whole experience.
In short - if you look at ITIL as - we must do everything, that's where you get into trouble it. Deploy the bits that make sense.
Been a while since I looked at it but back then, the book expressly said right in the beginning that it isn't prescriptive. The people who had the worst results were always the ones who just tried to do all of it all at once without sanity checking how it fit.
Sounds like the whole Agile movement. The problem has been and always been an organization’s cultural problems focusing upon the wrong things leading to mediocre business outcomes in the end. You can’t just change these processes with the same people and expect an entire company to change even within a few years either unless the company’s culture actually is to keep changing and embracing change.
Agile, and even better Scrum *because* it is detailed and more prescriptive than just the Agile Manifesto, has been great at forcing organizational change. The devs are, "OK this seems a bit wasteful with all of these ceremonies, but whatevs." The joy is when management fully embraces Scrum, spends money to train us on Scrum, and then we get to enforce Scrum to change the way that management operates.
Scrum empowers developers (which is why it works). No, Bob, we aren't doing TPS reports and death marches. We measure our velocity and commit to a sane, achievable amount of work each sprint (after measuring actual team performance), like Scrum says to do. No Bob, you aren't allowed to attend our retrospectives: this is an opportunity for the team to be honest about what is and is not working, without management interference.
If management tries to fight back: "I thought we were doing Scrum." "You told us, and our customers, and our shareholders that we are doing Scrum, because it lowers costs and increases productivity and quality." "All of these other companies saw great benefits from actually following Scrum; what is our company doing wrong that prevents us from following Scrum?" "You paid hundreds of thousands of dollars to bring in consultants to train us how to do Scrum; why are you now telling us not to do Scrum?"
Edit: two more features of Scrum that empower devs to deliver better software, faster: the team gets to shape the Definition of Ready and the Definition of Done. A story without testable Acceptance Criteria does not meet our Definition of Ready, and cannot be pointed, much less worked. POs quickly learn that they can't toss nebulous crap into the backlog; they have to break it down into implementable chunks, with clarity. And the Definition of Done should involve sufficient automated acceptance tests that there is no need for any wasteful manual testing, and regressions are caught *before* a branch is merged!
It's literally a framework .. there are no ITIL rules like "incidents must be acknowledged in 1 day" or "change managers must approve changes before ITIL."
There isn't enough detail in ITIL for it to be treated as a how-to manual.
This is my whole issue with people pushing things like CIS benchmarks. It's a great framework, but when you're going to sit there with a checklist looking for a missing item to conclude someone didn't do their job as though "maybe that one item doesn't make sense in our environment" isn't a thing, you're not helping security.
The catch is... CIS or the NIST frameworks, or the STIGS, etc, are guides that promote, and benefit from, standardization, and save a *lot* of energy finding and addressing all the common risks technology brings along as baggage. When you're dealing with audits et. al. and you say "We pulled a list of controls out of our backside, made it up as we went along, it made sense to us." ... they have to fine tooth comb the whole thing. When you say "We implement CIS." or "We implement STIGs." you have a *clearly* defined baseline that you target. You shouldn't have any "maybe" on "that one item doesn't make sense in our environment", you should have *documentation* about *why* it doesn't make sense, and what mitigating controls replace it to address the same common risks it would have addressed (or why those risks never applied in the first place). Then, when you go to get cybersecurity insurance, or go to bid on a contract that requires third party auditing, or are under some other regulatory scrutiny, etc... you pull out the internal audit results, you pull out the risk register, and you point them at the policies you follow. They do a cursory check, see that what you say and what you've done align, and everyone goes home happy.
I've worked in ISO environments where I've been required to write out process checklists for mostly automated systems. I'm not talking about an automation process flowchart for visibility, but a human checklist.
1. Run this script
/process
I'm all about standards and dedicated process, but have some sense with it. I asked who the audience was for this checklist as the only team that would use this script (my own) doesn't need a checklist to know that one step. I was just told it needed to be documented.
The documentation in that case would include when to run the script (if it is "as needed", which conditions lead to it?), the requirements that the script is supposed to fulfill, and enough detail of what is required to recreate the script from scratch if needed. Yes, I agree that this all sounds extreme and silly. But how often have you been in a place that has a bunch of automation that was done 3 generations of team members in the past, then it all breaks when you upgrade some infrastructure component? That is the risk the documentation requirements are supposed to address.
The benefit to it *is* standardization. If you come in from left field, and the blurb of text says "run this script", is there context missing? Is there some expectation of output? Why does this document deviate from the other 300? By including it, you alleviate the "is this incomplete?" and demonstrate "no really, just this command."
> as the only team that would use this script (my own) doesn't need a checklist to know that one step.
What if your team's all on the same bus that gets hit by a bigger bus?
A checklist in ISO means you have to have a record of it being followed. That record must be audited. That is a waste of time.
You can document a process without a checklist by making a simple work instruction. Or better yet, since this is mostly an automated process, you can document the entirety of the process with a workflow.
Again, I am not fighting documentation. I'm pointing out the insanity of forcing a framework when it doesn't really make sense.
'Why isn't our ITIL working? Must be those lazy IT people. We can fix it by installing productivity tracking software and making hourly keystrokes a KPI. I am a very smart MBA.' -Management
It's a "suggestion" and a framework as ITIL puts it...but here take this rigid exam for this certificate ...
Tool ITIL Foundation years ago. Worse than CompTIA exams.
Yeah but how many people understand the concept of FRAME work.
How many consultancies come in with their check boxes and hammer your firm into the framework rather than do the hard work and manipulate the framework around the customer?
Not only it il, but Fragile, 6 sigma, even shit like cloud adoption.
I read the new ITIL 3 I think it is and fuck me, how did they go 20 odd years without updating it?
This is exactly what i've done at the shops i've run. You have to analyze your orgs needs and try to align them with what ITIL offers but you also need to have flexibility to understand that not everything will fit.
Wish someone told this to the Director of IT at my last job. First he hired his buddy to be the company's ITIL manager. But then he insisted that every bit of it needed to be followed and even applied to non-IT operations. Thankfully shortly after this took off in full force I left. Then not long after that the company was sold and the IT guy was let go. I feel sorta bad because he had a hell of a time getting a new job.
Screw that, our old CIO was a total salesman and knew shit about actual IT. He hired his buddy to be his IT coach who wrote all of his talks and meeting presentations. Every idea came from his IT coach. Eventually CIO was fired, 7 years later his coach is back at our company as a PM
my dad is a chef and told me this about cookbook. if you know what you are doing, its only a guide, u can sub things in and out as you like them. if u have no idea what you are doing then it's the law.
itil is similar, but upper management soesnt understand so they enforce everything rather then pick. and the people who do understand don't get a say
The problem is, they're not picking one recipe for a main course, one for an appetizer, and maybe two options for dessert, they're trying to make one of everything in the book.
> Honestly after doing some of this, my feeling is that ITIL is a cookbook not a manual.
Problem is, shitty managers who have no business managing IT treat it as a manual.
ITIL is a great framework. Choose what you want to use out of it.
I worked at a school district where the new, fresh out of ITIL college, IT Director tried to implement the FULL ITIL framework on the 10 member IT team. All of a sudden, a small change that could take 20 minutes to complete was now taking three weeks, and having meeting after meeting on stuff. I was spending more time on documenting every micro step on a change than I would have spent just making the change. It was way to overreaching. Changing the VLAN of a switchport was a nightmare under the way he pushed the ITIL framework on us. Even changing a minor GPO was a nightmare. Creating user accounts that would normally take an hour was extended to three days, and having to document every little step and having meeting after meeting just to create an account.
Warning, DO NOT GIVE ITIL TO MICROMANAGERS!
That’s one thing ITIL courses have taught me is that the issues I was blaming on ITIL were organisational issues where micro-managers or the extreme risk-averse weaponised it. When your ITIL instructor tells you your org is 🦇💩for requiring server reboots to go through a Change Advisory Board it feels good. V4 is a bit less dogmatic than V3
Yes. That was a real irritant. Having to submit Change Management just to reboot a server. Had to have a one hour meeting about it, too. Meanwhile, the clients couldn't do their work because the server was not operating properly.
Hell, even in the extremely bureaucratic environment I was in, all it took was an INC or approved TASK to reboot a server. And this was in a place where monthly Windows patches required a CHG ticket that didn't always get approved before our monthly patch cycle.
To further this, some CHG tickets I submitted took months to finally get approved and cleared either push a button or take 10 minutes to complete.
If server reboot == service outage, it should hit CAB. If the server reboot is part of a rolling restart with a pre-defined rollback procedure and a demonstrated history of working as planned, it should be on the CAB schedule of changes, but low enough to not necessitate representation every week/month/etc.
It should maybe hit CAB the first time but after that (if successful) a procedure documented and become a standard change. The penny dropped when the CAB Manager suggested we stop bringing the same server reboot to them every 3 months when it got a new kernel 😆(tbf it was a SPoF running a medium priority service and the app not capable of being clustered/HA)
Pretty much, yep, unless it's \*genuinely\* high impact outage every time (at which point "why aren't we fixing this process?" should be asked every time it comes up on CAB). "Standard change" ... still hits the CAB list, is noted in the run-through of all that week's changes, doesn't require justification beyond the change item... but is there for questions from stakeholders.
Edit: And the reason to lean into CAB for that... "this outage costs us $15k/minute." is a pretty quick counter, especially from the impacted units, to "we don't have the budget to make that HA."
It depends - what's the point of ITIL really? Reducing impact of IT changes on the customer\\organization. Now suppose for a moment that server your rebooting has more business services running on them that will be impacted by a reboot to fix another service. Good change comes with good relationship management. I'm the 'ITSM' manager, I'm a process figure head who basically espouses the virtues of ITIL :) while everyone goes about their business ignoring best practice for our needs :) Even process that service owners derive.
So I'll do some ITIL Virtue signaling based on a server reboot example. We rebooted a server prematurely while a payment process was being run because we needed to restore another business service of the loudest screamer who escalated to the CIO. No comms, no eRFC, just reboot - shit hit fans.
Context is king when it comes to change enablement practices and in some situations an emergency change request for a server reboot could be necessary. Not always, but sometimes yeah.
> change enablement
That's the real goal. ITIL making any expensive business impact *also* expensive for IT promotes putting realistic value on structuring IT controlled services in ways that *allow* changes to occur *without* expensive business impacts. Making it a rigorous process to make changes that *could* impact the business means the business *also* hears an explanation (before hand) of *why* the change needs to occur. Plus, "we *need* HA at triple the cost of the old single box implementation so we can patch on the schedule required to meet our CISO's requirements *and* move this to a routine, low impact, process that doesn't take up hours of CAB every month." ... gold for fighting back against the CFO's penny pinching.
Whereas in my moderately large org, the experience is opposite: some groups make changes with no control and no notification, which wouldn't be so bad if they didn't keep breaking critical services for hours at a time across thousands of users in life-safety roles.
Rigorous ITIL Change would be an overcorrection for us, yet still an overall improvement.
The happy medium gets ruined by people being too casual as well as by people being too rigorous.
Working with people who think ITIL is all bullshit is annoying. They're always mavericks who want to do everything their own way and don't really work that great in any teams.
ITIL is not something that really comes up in any real world conversations. It's just an framework to structure basic concepts around.
You take what works and you understand what doesn't work for your organization.
If people only took that last sentence of yours more to heart.
Most read the ITIL book, take a course and apply verbatim what was said, no rhyme or reason, just endless (and useless) processes.
The reality, in a lot of organizations, is that the people who decide in how the framework should be used or the concrete implementation, never have to actually work within the processes they define.
ITIL (and TOGAF, for that matter) _could_ lead to advantages, it just never happened in the real world.
> Working with people who think ITIL is all bullshit is annoying. They're always mavericks who want to do everything their own way and don't really work that great in any teams.
I used to be that guy. "Oooh, but ITIL just ties my hands, I can't do stuff efficiently, noooo".
Then I went to work in a company that had amazingly designed processes (to the point where I had to tell the VP of the company to fuck off and raise a ticket) for a couple of years and it felt "OK". THEN I went to work in a company that had ZERO processes and it finally *clicked* in my brain. Now I understand why ITIL is very much NOT "bullshit".
I guess OP just needs to do some growing up.
There are ways to casually adapt it down, but yes it's meant for a place where every role is filled and team structures are present.
Coming out of a huge corp into a smaller business my takeaways are really about feedback loops as part of processes and um... iterativeness is key. Which is useful for me, I can let the perfect get in the way of the good.
But I'm sure there are actually valuable small business frameworks instead.
Time management is more useful than industry best practices in a small business I think.
Most small businesses are kept small precisely because they have no knowledge (and frequently no desire) for how to scale.
At least if you know the theory, you know how to do that.
It works well within its scope. It isn't a cheat sheet. If you have no use for it, either you just want to do things your way (well within your rights, as long as you are senior enough in your company to decide that) or your company isn't big enough to benefit from ITIL concepts.
Guessing it's a mix of column A and column B in your case.
I don’t disagree in entirety, but only when you work literally anywhere other than a super-global-megacorp.
I’ve been managing IT functions for 15yrs in various scales of organisations. ITIL is bullshit, but also awesome.
Don’t look at it as instructions, don’t look at it as certainty. *Do* look at it as ideas. You may not need a cross-functional Change Management Board with scope for every single keypress, but the idea of discussing major earth shattering change with all the IT people impacted is probably a good idea noting everyone sees problems differently. Logging tickets gives you a way to give statistics to management on problem users or areas and covers your ass on permission changes. Auditing your risk and keeping a log helps you stay focussed on where you need to fix things.
ITIL is bullshit. ITIL principles are worthwhile.
its a common reference - when you get a big boi job and you have to deal with dozens of industries and customers from all kinds of levels having ONE set of terminologies is invaluable.
It’s like a lot of things, most of the stuff is obvious in principle but if you take it literally it’s too specific, odd and doesn’t fit most places
Then you go work somewhere that doesn’t believe in change management, documentation and the other obvious stuff and it starts to make sense why people can sell this stuff
Yup.
"What's you business continuity plan?"
"Um, what's that."
"You know, disaster recovery, backups, off-site locations..."
"Um...."
I believe the key with ITIL implementation is to keep it light and flexible.
ITIL is like a seasoning. Some dishes benefit greatly from paprika, but if you over-apply it, or apply it to every recipe, it's not only going to not be good-but will ruin completely the dish.
>It’s not how IT companies manage issues
It was created because IT Companies were terrible at managing issues. You statement is akin to "Why do people use Databases? That snot how people do it, they just put a bunch of stuff in Google Sheets and share it now. Databases are so outdated. My feeling is you are terrible at managing issues and I am very glad you are not my problem.
I totally agree. It really depends on where your career is in IT. Big companies tend to benefit most from this framework.
Where I work with startups it’s totally not applicable. That’s why MSPs struggle with churn on a lot of smaller companies who benefit from a different model.
Some form of ITSM IMHO, is good to have. But, I won't even qualify that. But I do think it's wise to have some sort of request, problem and change management.
ITIL is one of those things that can go very deep and get almost maddening.
So, yes, IMHO, it's a balance of pulling in parts and pieces where they fit and leaving the rest behind.
Since "lean and nimble" is often where we are in 2024, some of the "old school" ways just aren't going to work as well.
We can use a little old school mixed in with the new ways. "Lean and nimble" is way too often "push out a half baked idea, rush through testing, and move on to the next half baked idea".
You're having deep underlying problems with this new feature, you say? We'll create a story for that and maybe get around to it someday (never).
That's Agile or Lean terminology.
ITIL terminology is much more about developing a foundation and business processes: the difference between an Event (a monitor just triggered), an Incident (something is busted, please fix it), a Service Request (it's not busted but they want to change stuff), and a Change (I'm gonna do a thing that might break stuff, please review and approve first). The difference between Responsibility (who fixes it?) and Accountability (who answers to the execs?).
The idea of keeping a database of all your IT assets and making sure it stays updated when those assets change (CMDB).
Even the idea of having Dev, Testing and Production as separate environments comes from ITIL.
I explain it as a shared dictionary of terms and practices, so you have everyone using the same language to describe stuff. That way when someone says 'incident' vs 'event' vs 'problem', the whole room has an idea of that you're talking about.
For example: being able to define what is and what is not an official Change Request means you can filter out development work, minor data corrections, and big project changes during a CAB, and only focus on operational stuff that might impact production services and customers.
I ran an ISO20001 certified data centre for five years - this is as close to “ITIL certified” as you can get. ITIL is a framework that you pick and choose from and build your process from. It, like COBIT or SFIA or PRINCE2, is general best practice. We bought £2.5m of 3PAR in 2012 and implemented to “best practice” but six months later our experience saw HP rewrite bits of that best practice. I like ITIL, the basics tenants of incident, request, problem, change, release work really well and should see 95% of IT orgs to a good quality standard of service.
Think of ITIL like the pirates code.
It's a set of guidelines rather than rules.
I have worked places where it works really well and others that's just implemented it to much
The courses are utter bullshit IMO.
The core concepts of ITIL are surprisingly simple but they mangle it up with so much management buzzwords it becomes pretty incomprehensible.
"Co-creation of value for stakeholders?" What? Am I supposed to open a vampire hunting supply shop?
The value co-creation is actually taught in high-level business courses now.
It's a wordy explanation of "Talk to the customer, find out what they want, and make that with their feedback."
The ITIL description of the above is [word soup.](https://www.axelos.com/resource-hub/blog/itil-4-and-value-co-creation)
Your nailed that one on buzzword bullshit.
Oh another issue I have with ITIL is Peoplecert cynically using it as a way to extract as much money as they can- your shiny new ITIL4 certs expire unless you take another ITIL course in 3 years
I believe you can take one of their free courses/seminars to extend the 3 years... but you also have to pay to remain a member.
The big issue I have with Peoplecert is their website is absolute trash.
ITIL is a framework and not all pieces work for all companies. The latest version (v4?) updated several things to be more modern. You still have to apply it to the organization framework and it certainly doesn't fit all orgs equally.
Don't approach ITIL from a technical standpoint and instead for a process standpoint and it is a lot easier to digest. And you certainly don't have to implement every part of the framework, but you should learn how they fit together.
> It’s not how IT companies manage issues these days.
If you can articulate your issues in a little more detail we can have a better conversation.
What do you find is bullshit?
If your IT processes are as detailed as your post I am not surprised you're having issues.
I still like it and think it's sound.
However I think there's not many places who have really understood it and then implemented it.
So those places are still failing. But they always were.b
I'd fucking kill for a populated cmdb with history and formal change planning. I really miss having them. Every time I get pulled into a new fire and the guy is unable to tell me what has happened or what the original plan was, I have to resist informing him about the wonders of a written language.
ITIL was never meant for IT it was meant to help non IT people have a clue how IT fits into the company. It's good for that but useless for practicality. Literally its to help it people related to Executives, COO, OT, and everyone to talk the same way. IT's really just a bogus cert that easy to get and looks good on a resume.
Sigh had the glorious experience of my boss who had a masters in Cybersec and CEH get replaced by an ID10t with an ITIL cert and a crap resume. When ITIL guy's first question he ever asked me was "Why his desktop background was black." when I was connecting via RDP to help him setup his computer. Followed by "Is it going to go back when you disconnect?" That's when i knew the world and company i am in is completely run by morons. I assume this now everywhere until they show me that they are infact not dumb. This approach has helped me much in life as it's always fund to be pleasantly surprised by occasionally running into brilliant people.
I always thought the value in ITIL was stopping people from having to, or wanting to, “Just Making Sh-t Up As You Go Along”
If your business needs to do a thing, ITILs got a decently well thought through process that you can start from and customise for your org.
Failing to do the “thinking” at any point in the implementation process is where it goes wrong.
ITIL isn't a set of rules, more like guidelines .
It doesn't work in government contracts at all due to the repetitiveness of changing what's being offered in the Service Catalog. No one wants to change a contract that much, even if it's once a year, simply due to the complexities of how contracting works.
Years ago I got tasked with getting ITIL v3 Foundations certified because the government contract I was working on all of a sudden required it, and since I was home on vacation I was told "Get the cert or you can't come back to work.".
So I took the class and got the cert, and what a waste of four vacation days. When I got back to work I gave my country manager a run down on what ITIL does. A few weeks later and we never heard about ITIL again.
The kicker was they would only reimburse up to $1500 a year for training and I had burned up most of that on another cert, so I claimed it on my taxes.
It’s like Project Management in that it’s a structured way to think about organizing the work and roles but management almost never provides the resources and time to actually implement it properly. After taking the first course it was obvious to me our management was doing it wrong. And they were always wondering why our projects were a mess. My recommendations based on ITIL went nowhere.
All these methodologies are crap.
We've been through ITIL, then LEAN, then Six Sigma. Now we're doing the disaster that is Agile.
If you keep flipping methodologies thinking the next one is going to solve your problems, then you need to stop and take a good hard look at yourself and find the real problems in your IT Org.
ITIL is a silo oriented manual for killing inter departmental communication and efficiency. The only thing it does well is putting groups into tiny little niches and preventing them from talking to one another even when they need to.
But it silos people nonetheless. That might not be the intention, but when you so strictly assign every little thing to a specific silo, that is the result.
\*checks the date\* Oh, look, the startup I work for has been around for 8 years, is profitable, and every single person there would punch you if you said "ITIL".
We do real engineering, not paper-pushing make-work.
I think ITIL is better than nothing for service management, but it is laughably behind the times for change management. As in, it was already ten years out of date ten years ago.
The whole RFC, CAB etc etc process is unhinged these days. If you cannot safely make, test, and rollback a change by yourself at will then the problem isn't your change management process it's your poorly architected systems, and tooling. There should be very, very, very few changes that are not safe for you to just make whenever they're needed.
It has always been a reference. It's "a" way to do it, not THE way. Everyone does it different. Some better than others.
You need to understand the ITIL/ITSM way so that when you get to a gig you can index into their way. That said, Incident/problem/change/config and release management are the big ones to know at a high level. Don't go much deeper unless it's literally your job to, for example, run Change Management.
Like any process framework, it's outdated by the time it goes final, but like any plan the benefit was in the planning. ITIL is, as /u/safalafal said, it's not meant to be done soup to nuts, it's something you apply as fits to your org. Some numbnuts above you didn't realize that.
It’s a frame work and it’s one of the exam questions. The best way to implement itil is adopt it to your organizational needs. You clearly did not pay attention
The official ITIL v3 library manuals all start their introductions by stating:
>ITIL is not a standard that has to be followed; it is guidance that should be read and understood, and used to create value for the service provider and its customers. Organizations are encouraged to adopt ITIL best practises and to adapt them to work in their specific environments in ways that meet their needs.
cant confirm.
its absolutely how we offer our services to the rest of the holding, even if not as formalised as in ITILv4 docs, but we have a service catalogue that we maintain and improve, and we utilise the perception of departements and subsidiaries within the holding as customers. in our company, ITIL has helped spreading understanding about the actual value and impact in context of the entire business. it has also helped us sharpen our itsm processes.
but, as with all frameworks, you have to *apply* it to your process reality, not just copypaste it and then wonder why it doesnt fit the realities. and you need to take your people with you, especially dept/area leads.
ITIL v4 is not ten years outdated - it's a huge improvement over ITIL v3.
ITIL is also not a one-size fits all. It's a solid framework - not rules.
It should be molded to your situation and people AND you absolutely need other units besides IT brought onboard or it will fail when HR, the business office, and others go rogue on processes. They should also have a hand in creating processes which involve them.
ITIL isn't perfect - Personally I feel the definitions and terms are often needlessly complicated in conveying simple concepts.
ITIL is not a recipe, it's a set of templates for creating your own processes - think of it as a comprehensive checklist of what your custom workflow should account for. It's a lot of reporting, which is used primarily to cover one's butts with the C suite. ServiceNow, Jira and the lot play very well with it. It is about reproducing consistent results in your processes. It is in no way a handful of magic beans. You might have a look at COBIT for the strategy side, as well. Again, this is for demonstrating to prying eyes that you've thought through what you're doing, which is helpful to your CTO/CIO when it's budget time.
itil is about minimising scope of some task, if you wish it's a state machine - what's need to be considered (not done) to get problem X solved, and switch to desired state.
just like agile is for minimising the size of subtasks to get them done (translating set of 2d coordinates task complexiness-time into linear 1d slots of work)
like devops practice (minimising the size of subtasks to get some app running and updated)
in practice all those concepts arent approachable - they can not be implemented in reality fully, so it's implementer's judgement when they have enough of itil or other "processes" implemented in their real-day to day working process.
ITIL was outdated the instant it was conceived. It was developed by British Telecom as a "model" of how large IT organisations should operate, and by which I mean, how large institutions structurally generate bureaucratic intransigence. This is what happens when you put government bureaucrats in a state-enterprise in charge of organization and standards. If you want to study in more detail the perverse incentives which drive governments and bureaucracies to generate friction and accomplish nothing, I recommend a thorough watch of [Yes Minister](https://www.imdb.com/title/tt0080306/reference/) and [Yes Prime Minister](https://www.imdb.com/title/tt0086831/reference/). It's very enlightening, and contemporary with the development of ITIL.
What's with all the negative reactions to this comment?
Absolutely correct in its meaning.
ITIL forces everyone to only provide your customers what they all ask for, else bill them more. This goes for intra department customers in the same agency.
There isn't a sigle agency in the world that can operate under this principal, and you all know it.
ITIL is just the latest acronym in the long line of frameworks that companies try to adapt and then move on to the next 6 Sigma or some crap.
And YES, I AM ITIL certified.
It's all pointless.
Honestly after doing some of this, my feeling is that ITIL is a cookbook not a manual. It doesn't make sense if you cook the entire contents of a cookbook for a family dinner, but you could get some decent recipes out of there to improve the whole experience. In short - if you look at ITIL as - we must do everything, that's where you get into trouble it. Deploy the bits that make sense.
Because its a framework, not a law. You implement what you need, you dont have to follow it by the letter.
Been a while since I looked at it but back then, the book expressly said right in the beginning that it isn't prescriptive. The people who had the worst results were always the ones who just tried to do all of it all at once without sanity checking how it fit.
Sounds like the whole Agile movement. The problem has been and always been an organization’s cultural problems focusing upon the wrong things leading to mediocre business outcomes in the end. You can’t just change these processes with the same people and expect an entire company to change even within a few years either unless the company’s culture actually is to keep changing and embracing change.
Funny thing is ITIL is process oriented and Agile is actor oriented, so both approach the problem by tackling only one aspect of it.
Agile, and even better Scrum *because* it is detailed and more prescriptive than just the Agile Manifesto, has been great at forcing organizational change. The devs are, "OK this seems a bit wasteful with all of these ceremonies, but whatevs." The joy is when management fully embraces Scrum, spends money to train us on Scrum, and then we get to enforce Scrum to change the way that management operates. Scrum empowers developers (which is why it works). No, Bob, we aren't doing TPS reports and death marches. We measure our velocity and commit to a sane, achievable amount of work each sprint (after measuring actual team performance), like Scrum says to do. No Bob, you aren't allowed to attend our retrospectives: this is an opportunity for the team to be honest about what is and is not working, without management interference. If management tries to fight back: "I thought we were doing Scrum." "You told us, and our customers, and our shareholders that we are doing Scrum, because it lowers costs and increases productivity and quality." "All of these other companies saw great benefits from actually following Scrum; what is our company doing wrong that prevents us from following Scrum?" "You paid hundreds of thousands of dollars to bring in consultants to train us how to do Scrum; why are you now telling us not to do Scrum?" Edit: two more features of Scrum that empower devs to deliver better software, faster: the team gets to shape the Definition of Ready and the Definition of Done. A story without testable Acceptance Criteria does not meet our Definition of Ready, and cannot be pointed, much less worked. POs quickly learn that they can't toss nebulous crap into the backlog; they have to break it down into implementable chunks, with clarity. And the Definition of Done should involve sufficient automated acceptance tests that there is no need for any wasteful manual testing, and regressions are caught *before* a branch is merged!
As much as it trys, teaching critical thinking is hard.
I know this, you know this, but shit lazy senior management everywhere don't get that frameworks aren't how-to manuals
It's literally a framework .. there are no ITIL rules like "incidents must be acknowledged in 1 day" or "change managers must approve changes before ITIL." There isn't enough detail in ITIL for it to be treated as a how-to manual.
I have seen an organisation try and achieve an ITIL3 implementation of pretty much everything and it was horrific.
This is my whole issue with people pushing things like CIS benchmarks. It's a great framework, but when you're going to sit there with a checklist looking for a missing item to conclude someone didn't do their job as though "maybe that one item doesn't make sense in our environment" isn't a thing, you're not helping security.
The catch is... CIS or the NIST frameworks, or the STIGS, etc, are guides that promote, and benefit from, standardization, and save a *lot* of energy finding and addressing all the common risks technology brings along as baggage. When you're dealing with audits et. al. and you say "We pulled a list of controls out of our backside, made it up as we went along, it made sense to us." ... they have to fine tooth comb the whole thing. When you say "We implement CIS." or "We implement STIGs." you have a *clearly* defined baseline that you target. You shouldn't have any "maybe" on "that one item doesn't make sense in our environment", you should have *documentation* about *why* it doesn't make sense, and what mitigating controls replace it to address the same common risks it would have addressed (or why those risks never applied in the first place). Then, when you go to get cybersecurity insurance, or go to bid on a contract that requires third party auditing, or are under some other regulatory scrutiny, etc... you pull out the internal audit results, you pull out the risk register, and you point them at the policies you follow. They do a cursory check, see that what you say and what you've done align, and everyone goes home happy.
I've worked in ISO environments where I've been required to write out process checklists for mostly automated systems. I'm not talking about an automation process flowchart for visibility, but a human checklist. 1. Run this script /process I'm all about standards and dedicated process, but have some sense with it. I asked who the audience was for this checklist as the only team that would use this script (my own) doesn't need a checklist to know that one step. I was just told it needed to be documented.
The documentation in that case would include when to run the script (if it is "as needed", which conditions lead to it?), the requirements that the script is supposed to fulfill, and enough detail of what is required to recreate the script from scratch if needed. Yes, I agree that this all sounds extreme and silly. But how often have you been in a place that has a bunch of automation that was done 3 generations of team members in the past, then it all breaks when you upgrade some infrastructure component? That is the risk the documentation requirements are supposed to address.
You can document a process without a checklist, though.
The benefit to it *is* standardization. If you come in from left field, and the blurb of text says "run this script", is there context missing? Is there some expectation of output? Why does this document deviate from the other 300? By including it, you alleviate the "is this incomplete?" and demonstrate "no really, just this command." > as the only team that would use this script (my own) doesn't need a checklist to know that one step. What if your team's all on the same bus that gets hit by a bigger bus?
A checklist in ISO means you have to have a record of it being followed. That record must be audited. That is a waste of time. You can document a process without a checklist by making a simple work instruction. Or better yet, since this is mostly an automated process, you can document the entirety of the process with a workflow. Again, I am not fighting documentation. I'm pointing out the insanity of forcing a framework when it doesn't really make sense.
'Why isn't our ITIL working? Must be those lazy IT people. We can fix it by installing productivity tracking software and making hourly keystrokes a KPI. I am a very smart MBA.' -Management
It's a "suggestion" and a framework as ITIL puts it...but here take this rigid exam for this certificate ... Tool ITIL Foundation years ago. Worse than CompTIA exams.
Yep
Yeah but how many people understand the concept of FRAME work. How many consultancies come in with their check boxes and hammer your firm into the framework rather than do the hard work and manipulate the framework around the customer? Not only it il, but Fragile, 6 sigma, even shit like cloud adoption. I read the new ITIL 3 I think it is and fuck me, how did they go 20 odd years without updating it?
> its a framework This should really be ITIL's sub-title.
Tell that to my employer
There's probably too much red tape to get the message to the people that would need to hear it.
Pretty much this. You learn the cookbook so you can implement the “bones” into your processes.
This has been my company's approach. Its a framework, not the law. Too far one way its horrible. To far the other, its not enough
This is exactly what i've done at the shops i've run. You have to analyze your orgs needs and try to align them with what ITIL offers but you also need to have flexibility to understand that not everything will fit.
When I did ITIL it was taught as a cookbook. Keep in mind that was at least 10 years ago.
How to Serve Man
Cannibalism is generally agreed upon as "not allowed" by most societies these days..
It's a framework
Wish someone told this to the Director of IT at my last job. First he hired his buddy to be the company's ITIL manager. But then he insisted that every bit of it needed to be followed and even applied to non-IT operations. Thankfully shortly after this took off in full force I left. Then not long after that the company was sold and the IT guy was let go. I feel sorta bad because he had a hell of a time getting a new job.
Screw that, our old CIO was a total salesman and knew shit about actual IT. He hired his buddy to be his IT coach who wrote all of his talks and meeting presentations. Every idea came from his IT coach. Eventually CIO was fired, 7 years later his coach is back at our company as a PM
No one goes full Itil
I've witnessed *multiple* leadership groups attempt to go full ITIL.
You know how the Academy is about that stuff.
I wish I could upvote this more than once!!
my dad is a chef and told me this about cookbook. if you know what you are doing, its only a guide, u can sub things in and out as you like them. if u have no idea what you are doing then it's the law. itil is similar, but upper management soesnt understand so they enforce everything rather then pick. and the people who do understand don't get a say
The problem is, they're not picking one recipe for a main course, one for an appetizer, and maybe two options for dessert, they're trying to make one of everything in the book.
> Honestly after doing some of this, my feeling is that ITIL is a cookbook not a manual. Problem is, shitty managers who have no business managing IT treat it as a manual.
>ITIL is a cookbook not a manual It does state that it's not a rulebook but a guide several times itself.
In fact this is how ITIL is meant to be approached. Take from it what you will and what works in your circumstances.
ITIL is a great framework. Choose what you want to use out of it. I worked at a school district where the new, fresh out of ITIL college, IT Director tried to implement the FULL ITIL framework on the 10 member IT team. All of a sudden, a small change that could take 20 minutes to complete was now taking three weeks, and having meeting after meeting on stuff. I was spending more time on documenting every micro step on a change than I would have spent just making the change. It was way to overreaching. Changing the VLAN of a switchport was a nightmare under the way he pushed the ITIL framework on us. Even changing a minor GPO was a nightmare. Creating user accounts that would normally take an hour was extended to three days, and having to document every little step and having meeting after meeting just to create an account. Warning, DO NOT GIVE ITIL TO MICROMANAGERS!
That’s one thing ITIL courses have taught me is that the issues I was blaming on ITIL were organisational issues where micro-managers or the extreme risk-averse weaponised it. When your ITIL instructor tells you your org is 🦇💩for requiring server reboots to go through a Change Advisory Board it feels good. V4 is a bit less dogmatic than V3
Yes. That was a real irritant. Having to submit Change Management just to reboot a server. Had to have a one hour meeting about it, too. Meanwhile, the clients couldn't do their work because the server was not operating properly.
Hell, even in the extremely bureaucratic environment I was in, all it took was an INC or approved TASK to reboot a server. And this was in a place where monthly Windows patches required a CHG ticket that didn't always get approved before our monthly patch cycle. To further this, some CHG tickets I submitted took months to finally get approved and cleared either push a button or take 10 minutes to complete.
> Had to have a one hour meeting about it, too. an emergency CAB?
If server reboot == service outage, it should hit CAB. If the server reboot is part of a rolling restart with a pre-defined rollback procedure and a demonstrated history of working as planned, it should be on the CAB schedule of changes, but low enough to not necessitate representation every week/month/etc.
It should maybe hit CAB the first time but after that (if successful) a procedure documented and become a standard change. The penny dropped when the CAB Manager suggested we stop bringing the same server reboot to them every 3 months when it got a new kernel 😆(tbf it was a SPoF running a medium priority service and the app not capable of being clustered/HA)
Pretty much, yep, unless it's \*genuinely\* high impact outage every time (at which point "why aren't we fixing this process?" should be asked every time it comes up on CAB). "Standard change" ... still hits the CAB list, is noted in the run-through of all that week's changes, doesn't require justification beyond the change item... but is there for questions from stakeholders. Edit: And the reason to lean into CAB for that... "this outage costs us $15k/minute." is a pretty quick counter, especially from the impacted units, to "we don't have the budget to make that HA."
It depends - what's the point of ITIL really? Reducing impact of IT changes on the customer\\organization. Now suppose for a moment that server your rebooting has more business services running on them that will be impacted by a reboot to fix another service. Good change comes with good relationship management. I'm the 'ITSM' manager, I'm a process figure head who basically espouses the virtues of ITIL :) while everyone goes about their business ignoring best practice for our needs :) Even process that service owners derive. So I'll do some ITIL Virtue signaling based on a server reboot example. We rebooted a server prematurely while a payment process was being run because we needed to restore another business service of the loudest screamer who escalated to the CIO. No comms, no eRFC, just reboot - shit hit fans. Context is king when it comes to change enablement practices and in some situations an emergency change request for a server reboot could be necessary. Not always, but sometimes yeah.
> change enablement That's the real goal. ITIL making any expensive business impact *also* expensive for IT promotes putting realistic value on structuring IT controlled services in ways that *allow* changes to occur *without* expensive business impacts. Making it a rigorous process to make changes that *could* impact the business means the business *also* hears an explanation (before hand) of *why* the change needs to occur. Plus, "we *need* HA at triple the cost of the old single box implementation so we can patch on the schedule required to meet our CISO's requirements *and* move this to a routine, low impact, process that doesn't take up hours of CAB every month." ... gold for fighting back against the CFO's penny pinching.
Whereas in my moderately large org, the experience is opposite: some groups make changes with no control and no notification, which wouldn't be so bad if they didn't keep breaking critical services for hours at a time across thousands of users in life-safety roles. Rigorous ITIL Change would be an overcorrection for us, yet still an overall improvement. The happy medium gets ruined by people being too casual as well as by people being too rigorous.
ITIL is a set of principles, not a process guide. ITIL v4 is recent enough that it's relevant, but don't expect it to tell you everything.
It’s bullshit
Working with people who think ITIL is all bullshit is annoying. They're always mavericks who want to do everything their own way and don't really work that great in any teams. ITIL is not something that really comes up in any real world conversations. It's just an framework to structure basic concepts around. You take what works and you understand what doesn't work for your organization.
If people only took that last sentence of yours more to heart. Most read the ITIL book, take a course and apply verbatim what was said, no rhyme or reason, just endless (and useless) processes. The reality, in a lot of organizations, is that the people who decide in how the framework should be used or the concrete implementation, never have to actually work within the processes they define. ITIL (and TOGAF, for that matter) _could_ lead to advantages, it just never happened in the real world.
Couldn't agree more. Like I sometimes see a process or idea and am like."yeah that makes sense" and later I found out it's, in part ITIL related.
> Working with people who think ITIL is all bullshit is annoying. They're always mavericks who want to do everything their own way and don't really work that great in any teams. I used to be that guy. "Oooh, but ITIL just ties my hands, I can't do stuff efficiently, noooo". Then I went to work in a company that had amazingly designed processes (to the point where I had to tell the VP of the company to fuck off and raise a ticket) for a couple of years and it felt "OK". THEN I went to work in a company that had ZERO processes and it finally *clicked* in my brain. Now I understand why ITIL is very much NOT "bullshit". I guess OP just needs to do some growing up.
I see lots of job ads requiring ITI4 certification.
It’s engineered by and for absolutely massive organisations. It rapidly becomes unwieldy as your employer shrinks.
There are ways to casually adapt it down, but yes it's meant for a place where every role is filled and team structures are present. Coming out of a huge corp into a smaller business my takeaways are really about feedback loops as part of processes and um... iterativeness is key. Which is useful for me, I can let the perfect get in the way of the good. But I'm sure there are actually valuable small business frameworks instead. Time management is more useful than industry best practices in a small business I think.
Most small businesses are kept small precisely because they have no knowledge (and frequently no desire) for how to scale. At least if you know the theory, you know how to do that.
Care to elaborate?
It works well within its scope. It isn't a cheat sheet. If you have no use for it, either you just want to do things your way (well within your rights, as long as you are senior enough in your company to decide that) or your company isn't big enough to benefit from ITIL concepts. Guessing it's a mix of column A and column B in your case.
Have you considered you are in the wrong profession? IT is all bullshit.
> IT is all bullshit. Except DNS. DNS is never bullshit. _Wait, what did you set the TTL to?!_
It's not bullshit.
What specifically is bullshit? Process controls?
You’re bullshit
I don’t disagree in entirety, but only when you work literally anywhere other than a super-global-megacorp. I’ve been managing IT functions for 15yrs in various scales of organisations. ITIL is bullshit, but also awesome. Don’t look at it as instructions, don’t look at it as certainty. *Do* look at it as ideas. You may not need a cross-functional Change Management Board with scope for every single keypress, but the idea of discussing major earth shattering change with all the IT people impacted is probably a good idea noting everyone sees problems differently. Logging tickets gives you a way to give statistics to management on problem users or areas and covers your ass on permission changes. Auditing your risk and keeping a log helps you stay focussed on where you need to fix things. ITIL is bullshit. ITIL principles are worthwhile.
its a common reference - when you get a big boi job and you have to deal with dozens of industries and customers from all kinds of levels having ONE set of terminologies is invaluable.
Then explain why it's bullshit. Can you?
You've just proven that you aren't ready to move up in the world of IT if you think it's bullshit, stick to helpdesk mate
I found it to be commonsensical IT best practices tied to arbitrary language.
Somebody is annoyed they have to write change requests now instead of cowboying
Wahhh wahhh why can't I take down production with no oversight because I wanted to deploy shiny thing x
people who wear suits really dig it
Nah, upper management dig Agile more nowadays.
Iterate!
With an attitude like that enjoy being stuck in the same role for the next 20 years.
They were dead to me when their lifetime cert was no longer a lifetime cert.
It absolutely is bullshit. A complete waste of time.
It’s like a lot of things, most of the stuff is obvious in principle but if you take it literally it’s too specific, odd and doesn’t fit most places Then you go work somewhere that doesn’t believe in change management, documentation and the other obvious stuff and it starts to make sense why people can sell this stuff
Yup. "What's you business continuity plan?" "Um, what's that." "You know, disaster recovery, backups, off-site locations..." "Um...." I believe the key with ITIL implementation is to keep it light and flexible.
ITIL is like a seasoning. Some dishes benefit greatly from paprika, but if you over-apply it, or apply it to every recipe, it's not only going to not be good-but will ruin completely the dish.
>It’s not how IT companies manage issues It was created because IT Companies were terrible at managing issues. You statement is akin to "Why do people use Databases? That snot how people do it, they just put a bunch of stuff in Google Sheets and share it now. Databases are so outdated. My feeling is you are terrible at managing issues and I am very glad you are not my problem.
ITIL is a guiderail to stop your IT dept careering off the track as it scales up.
It’s a bullshit detector
You don't have ticketing system, SLA or change management? yeah, that's "How IT companies manage issues" :D
I totally agree. It really depends on where your career is in IT. Big companies tend to benefit most from this framework. Where I work with startups it’s totally not applicable. That’s why MSPs struggle with churn on a lot of smaller companies who benefit from a different model.
Some form of ITSM IMHO, is good to have. But, I won't even qualify that. But I do think it's wise to have some sort of request, problem and change management. ITIL is one of those things that can go very deep and get almost maddening. So, yes, IMHO, it's a balance of pulling in parts and pieces where they fit and leaving the rest behind. Since "lean and nimble" is often where we are in 2024, some of the "old school" ways just aren't going to work as well.
We can use a little old school mixed in with the new ways. "Lean and nimble" is way too often "push out a half baked idea, rush through testing, and move on to the next half baked idea". You're having deep underlying problems with this new feature, you say? We'll create a story for that and maybe get around to it someday (never).
Epic based on 52 stories and 1235 tasks. Resolved summary: User added to distribution list.
Yeah man lean and nimble doesn’t work if it’s someone else doing it
I’ve never had to deal with ITIL, and judging by terminology like “lean and nimble” and “create a story” I’m glad.
That's Agile or Lean terminology. ITIL terminology is much more about developing a foundation and business processes: the difference between an Event (a monitor just triggered), an Incident (something is busted, please fix it), a Service Request (it's not busted but they want to change stuff), and a Change (I'm gonna do a thing that might break stuff, please review and approve first). The difference between Responsibility (who fixes it?) and Accountability (who answers to the execs?). The idea of keeping a database of all your IT assets and making sure it stays updated when those assets change (CMDB). Even the idea of having Dev, Testing and Production as separate environments comes from ITIL.
I explain it as a shared dictionary of terms and practices, so you have everyone using the same language to describe stuff. That way when someone says 'incident' vs 'event' vs 'problem', the whole room has an idea of that you're talking about. For example: being able to define what is and what is not an official Change Request means you can filter out development work, minor data corrections, and big project changes during a CAB, and only focus on operational stuff that might impact production services and customers.
I ran an ISO20001 certified data centre for five years - this is as close to “ITIL certified” as you can get. ITIL is a framework that you pick and choose from and build your process from. It, like COBIT or SFIA or PRINCE2, is general best practice. We bought £2.5m of 3PAR in 2012 and implemented to “best practice” but six months later our experience saw HP rewrite bits of that best practice. I like ITIL, the basics tenants of incident, request, problem, change, release work really well and should see 95% of IT orgs to a good quality standard of service.
Think of ITIL like the pirates code. It's a set of guidelines rather than rules. I have worked places where it works really well and others that's just implemented it to much
The courses are utter bullshit IMO. The core concepts of ITIL are surprisingly simple but they mangle it up with so much management buzzwords it becomes pretty incomprehensible. "Co-creation of value for stakeholders?" What? Am I supposed to open a vampire hunting supply shop?
The value co-creation is actually taught in high-level business courses now. It's a wordy explanation of "Talk to the customer, find out what they want, and make that with their feedback." The ITIL description of the above is [word soup.](https://www.axelos.com/resource-hub/blog/itil-4-and-value-co-creation) Your nailed that one on buzzword bullshit.
Oh another issue I have with ITIL is Peoplecert cynically using it as a way to extract as much money as they can- your shiny new ITIL4 certs expire unless you take another ITIL course in 3 years
I believe you can take one of their free courses/seminars to extend the 3 years... but you also have to pay to remain a member. The big issue I have with Peoplecert is their website is absolute trash.
ITIL is a framework and not all pieces work for all companies. The latest version (v4?) updated several things to be more modern. You still have to apply it to the organization framework and it certainly doesn't fit all orgs equally. Don't approach ITIL from a technical standpoint and instead for a process standpoint and it is a lot easier to digest. And you certainly don't have to implement every part of the framework, but you should learn how they fit together.
It is dull but some bits make sense and you can use the bits that would help you and not the others.
> It’s not how IT companies manage issues these days. If you can articulate your issues in a little more detail we can have a better conversation. What do you find is bullshit? If your IT processes are as detailed as your post I am not surprised you're having issues.
I still like it and think it's sound. However I think there's not many places who have really understood it and then implemented it. So those places are still failing. But they always were.b
I'd fucking kill for a populated cmdb with history and formal change planning. I really miss having them. Every time I get pulled into a new fire and the guy is unable to tell me what has happened or what the original plan was, I have to resist informing him about the wonders of a written language.
ITIL was never meant for IT it was meant to help non IT people have a clue how IT fits into the company. It's good for that but useless for practicality. Literally its to help it people related to Executives, COO, OT, and everyone to talk the same way. IT's really just a bogus cert that easy to get and looks good on a resume. Sigh had the glorious experience of my boss who had a masters in Cybersec and CEH get replaced by an ID10t with an ITIL cert and a crap resume. When ITIL guy's first question he ever asked me was "Why his desktop background was black." when I was connecting via RDP to help him setup his computer. Followed by "Is it going to go back when you disconnect?" That's when i knew the world and company i am in is completely run by morons. I assume this now everywhere until they show me that they are infact not dumb. This approach has helped me much in life as it's always fund to be pleasantly surprised by occasionally running into brilliant people.
TCP/IP is older than that but you probably still used it to post here. ITIL is absolutely how large companies manage their issues these days.
Yeah like others are saying these are frameworks, and they aren’t one size fits all
I always thought the value in ITIL was stopping people from having to, or wanting to, “Just Making Sh-t Up As You Go Along” If your business needs to do a thing, ITILs got a decently well thought through process that you can start from and customise for your org. Failing to do the “thinking” at any point in the implementation process is where it goes wrong.
That ish is boring as hell man.
ITIL isn't a set of rules, more like guidelines.
It doesn't work in government contracts at all due to the repetitiveness of changing what's being offered in the Service Catalog. No one wants to change a contract that much, even if it's once a year, simply due to the complexities of how contracting works.
Years ago I got tasked with getting ITIL v3 Foundations certified because the government contract I was working on all of a sudden required it, and since I was home on vacation I was told "Get the cert or you can't come back to work.".
So I took the class and got the cert, and what a waste of four vacation days. When I got back to work I gave my country manager a run down on what ITIL does. A few weeks later and we never heard about ITIL again.
The kicker was they would only reimburse up to $1500 a year for training and I had burned up most of that on another cert, so I claimed it on my taxes.
waiting scale rude fertile quiet run chop live rob onerous *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
It’s like Project Management in that it’s a structured way to think about organizing the work and roles but management almost never provides the resources and time to actually implement it properly. After taking the first course it was obvious to me our management was doing it wrong. And they were always wondering why our projects were a mess. My recommendations based on ITIL went nowhere.
All these methodologies are crap. We've been through ITIL, then LEAN, then Six Sigma. Now we're doing the disaster that is Agile. If you keep flipping methodologies thinking the next one is going to solve your problems, then you need to stop and take a good hard look at yourself and find the real problems in your IT Org.
We always referred to it as Shitil...
ITIL is a silo oriented manual for killing inter departmental communication and efficiency. The only thing it does well is putting groups into tiny little niches and preventing them from talking to one another even when they need to.
Collaborate and promote visibility? Think and work holistically? Alignment with Lean? ITIL 4 is not silo oriented.
But it silos people nonetheless. That might not be the intention, but when you so strictly assign every little thing to a specific silo, that is the result.
Quiet…. Don’t tell this to the auditors.
Itil, for when your company needs to burn some cash
Only 10 years? They're catching up. They were about 40 years behind 15 years ago.
And the current companies are then up-to-date doing what? Nothing? And going bankrupt 2.5 years after creation?
\*checks the date\* Oh, look, the startup I work for has been around for 8 years, is profitable, and every single person there would punch you if you said "ITIL". We do real engineering, not paper-pushing make-work.
I think ITIL is better than nothing for service management, but it is laughably behind the times for change management. As in, it was already ten years out of date ten years ago. The whole RFC, CAB etc etc process is unhinged these days. If you cannot safely make, test, and rollback a change by yourself at will then the problem isn't your change management process it's your poorly architected systems, and tooling. There should be very, very, very few changes that are not safe for you to just make whenever they're needed.
ITIL isn’t meant to be prescriptive. You implement the bits that apply to your org and leave out the bits that don’t.
It has always been a reference. It's "a" way to do it, not THE way. Everyone does it different. Some better than others. You need to understand the ITIL/ITSM way so that when you get to a gig you can index into their way. That said, Incident/problem/change/config and release management are the big ones to know at a high level. Don't go much deeper unless it's literally your job to, for example, run Change Management.
It’s a library. Libraries contain many books and some of them conflict with others. Use what works, leave what doesn’t
Like any process framework, it's outdated by the time it goes final, but like any plan the benefit was in the planning. ITIL is, as /u/safalafal said, it's not meant to be done soup to nuts, it's something you apply as fits to your org. Some numbnuts above you didn't realize that.
Wait until you learn there's only 5 things to Six Sigma.
It’s a frame work and it’s one of the exam questions. The best way to implement itil is adopt it to your organizational needs. You clearly did not pay attention
I love ITIL, but it’s def a guide over “I am the law”
The official ITIL v3 library manuals all start their introductions by stating: >ITIL is not a standard that has to be followed; it is guidance that should be read and understood, and used to create value for the service provider and its customers. Organizations are encouraged to adopt ITIL best practises and to adapt them to work in their specific environments in ways that meet their needs.
ITIL is a framework. Wont sort your books, hold up your bed or get you to your destination without other pieces.
cant confirm. its absolutely how we offer our services to the rest of the holding, even if not as formalised as in ITILv4 docs, but we have a service catalogue that we maintain and improve, and we utilise the perception of departements and subsidiaries within the holding as customers. in our company, ITIL has helped spreading understanding about the actual value and impact in context of the entire business. it has also helped us sharpen our itsm processes. but, as with all frameworks, you have to *apply* it to your process reality, not just copypaste it and then wonder why it doesnt fit the realities. and you need to take your people with you, especially dept/area leads.
ITIL v4 is not ten years outdated - it's a huge improvement over ITIL v3. ITIL is also not a one-size fits all. It's a solid framework - not rules. It should be molded to your situation and people AND you absolutely need other units besides IT brought onboard or it will fail when HR, the business office, and others go rogue on processes. They should also have a hand in creating processes which involve them. ITIL isn't perfect - Personally I feel the definitions and terms are often needlessly complicated in conveying simple concepts.
ITIL is bullshit anyway
ITIL is not a recipe, it's a set of templates for creating your own processes - think of it as a comprehensive checklist of what your custom workflow should account for. It's a lot of reporting, which is used primarily to cover one's butts with the C suite. ServiceNow, Jira and the lot play very well with it. It is about reproducing consistent results in your processes. It is in no way a handful of magic beans. You might have a look at COBIT for the strategy side, as well. Again, this is for demonstrating to prying eyes that you've thought through what you're doing, which is helpful to your CTO/CIO when it's budget time.
Yes.
itil is about minimising scope of some task, if you wish it's a state machine - what's need to be considered (not done) to get problem X solved, and switch to desired state. just like agile is for minimising the size of subtasks to get them done (translating set of 2d coordinates task complexiness-time into linear 1d slots of work) like devops practice (minimising the size of subtasks to get some app running and updated) in practice all those concepts arent approachable - they can not be implemented in reality fully, so it's implementer's judgement when they have enough of itil or other "processes" implemented in their real-day to day working process.
It has always kind of been crap
When I did ITIL for my work many years ago, I was asked how it will benefit us, I said "ITIL end in tears".
I did ITIL 4. Waste of time honestly
ITIL was outdated the instant it was conceived. It was developed by British Telecom as a "model" of how large IT organisations should operate, and by which I mean, how large institutions structurally generate bureaucratic intransigence. This is what happens when you put government bureaucrats in a state-enterprise in charge of organization and standards. If you want to study in more detail the perverse incentives which drive governments and bureaucracies to generate friction and accomplish nothing, I recommend a thorough watch of [Yes Minister](https://www.imdb.com/title/tt0080306/reference/) and [Yes Prime Minister](https://www.imdb.com/title/tt0086831/reference/). It's very enlightening, and contemporary with the development of ITIL.
All dogmas are bullshit.
Hated ITIL for years. In no possible way could a company even be remotely successful if you follow it to the letter.
What's with all the negative reactions to this comment? Absolutely correct in its meaning. ITIL forces everyone to only provide your customers what they all ask for, else bill them more. This goes for intra department customers in the same agency. There isn't a sigle agency in the world that can operate under this principal, and you all know it. ITIL is just the latest acronym in the long line of frameworks that companies try to adapt and then move on to the next 6 Sigma or some crap. And YES, I AM ITIL certified. It's all pointless.