Skip to main content

Needles, Haystacks, and Incident Management

Something I've seen over and over is a slew of non-incidents sitting in an incident management system.  Sometimes they're generic service requests, sometimes they're changes, other times they may be test defects.  My take is this: those things are important, but putting them together makes reporting a pain and makes it easier to lose important incident information in the "other requests" haystack.

Let incident management be for incidents, and find other homes for those other items.  Don't look for needles in haystacks.   Make a pile of needles and a stack of hay - you'll be happier and more effective that way.

Comments

Popular posts from this blog

Intro and This Week's Wisdom #1

In my previous job running operations and maintenance for UFMS at HHS, one my contractors starting writing down things I'd said in meetings.  Not because he needed notes of what I was saying in context so much - but things he found amusing or useful or instructive or somehow worth being able to look back to. When I left that job, he made a PowerPoint of these for my going-away. A lot of people have enjoyed these and so I've decided to start posted some of these old ones he'd collected along with some new ones that I've said in more recent days. I probably can't name names, but I'll give a little context about each.  There's usually a point to them which is applicable in terms of IT Service Management and Operations.  Or life.  Or something. And now, this week's Ed-wisdom: "My friend, changing the oil will NOT fix your flat tire." The lesson to be learned - application of root cause analysis to understand what you're

Quotable Quote #2 - On staying in your lane

"It's like watching five-year-olds playing soccer.  Everyone on the field in a big cloud of dust around the ball." Teams don't win when everyone is trying to do the same job.   Imagine you've got a critical incident. Even if you don't have a well documented process (and why don't you, hmmm?) it's pretty clear certain things need to happen.   If you're living the good life, you'll have someone coordinating the incident, the right subject matter experts analyzing and resolving, communications specialists informing the customers and stakeholders, and others as needed. If you're dealing with a less mature team, you'll often find a chaotic scene.  Perhaps two people are checking out the same piece of equipment, three others are looking at the same log files, and meanwhile, nobody has bothered to notify anyone because they were all too busy trying to fix things. Not only do you end up with the inevitable case of "too man