When is a project a Project? How to prevent the buildup of backlogged requests

I just wrote something up (internal wiki) that I thought was common knowledge, but I think it's one of those soft-skills things that makes total sense once you hear about it - but somebody needs to tell you.

I think of one of the reasons that IT (at times) intimidates the business - or why IT gets the cold shoulder when it comes to process improvement efforts - is that we can get a bit too wrapped up in the Art and Science of Project Management. It's hard to build that business-savvy image when every new idea that comes your way is met with a 12-month waterfall Gantt, a copy of the PMBOK, and a formal sign-off sheet.

Howzabout a little common sense first? When you hear about an interesting idea from someone in the business, spend some face time with the requestor. E-mails and phone calls will not suffice; you can't build a relationship that way. Have a conversation about what they want vs. what they need ...

• Sanity Check: Do they want something huge? Impossible? Impractical? is a great idea, but completely out of line with current corporate strategies/priorities? If so, help them understand they are boiling the ocean, it's overkill and/or not likely to get worked on in the next 12 months. If they agree that this is a bit of a stretch - hey, you're done! You've successfully stopped a bunch of needless administrivia work before it even started!
• If they still think it's a great idea, consider capturing the magic by putting together a simple (i.e. quick) Project Charter document, and adding it to your "master list" of projects. Then, immediately put the project on Hold. It will be in your database / list forever, we won't lose track of the Great Ideas embedded within ... but it will be off of our immediate radar screen.
• Training Issue: Are they asking for something that can be done in a different way (ie. shooting rabbits with a bazooka)? Maybe they don't understand all that (insert your favorite ERP here) has to offer. Can we solve their request with some training?
• Quick Hit: If they're asking for something that is twenty effort hours (or less), has minimal impact on a small number of people (ie. no training will be needed), and could get taken care of over a few days/weeks - consider it "filler work", and don't bother creating a formal Project for the effort. The business will love that you're delivering value without bureaucracy. Your brain will relish the chance to fill-in the dead time between meetings. And, your boss will/should dig it because it's lagniappe - that little something extra. Sometimes, all they need is a report tweak or a simple data download ... Web 2.0 is not the answer for everything.
• Caveat: Don't let this become the way that everything gets done. If a project is big enough, you should go through the proper level of rigor - it ensures that your efforts will be sustainable.
• The Real Thing: Ok, if you've made it this far - this idea is good, it's not too small, will involve a number of IT and business resources that need coordination and communication - i.e. Project Management - then yes, you need to follow your IT group's standard process. No shortcuts (from here on out ...)