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.
"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