Wherever I go, I hear the same thing: Project Management methodologies are overkill for small projects or work requests (the threshold for which I've heard defined anywhere from 80 hours to 500 hours---I tend to lean toward the larger number).
Even with that, I still believe that the same "thinking steps" and phases should apply no matter how large or small the initiative. With that in mind, I typically like to have the same high level framework for any size initiative, and let the details scale up or down based on the size (with more or less formality accordingly).
Let's face it, you still need to understand what the goals and objectives are, you still need to provide an estimate, and you still need communicate well and deliver in an organized fashion.
When challenged that the same steps aren't applicable across projects and work requests, I typically respond with, "Which of the steps do you believe aren't necessary and why?" Often, it turns out that most of the steps are still needed, they just need to be scaled back or made less formal for smaller efforts.
Tom Barnett has a nice writeup in Computerworld about a "playbook" approach he uses for the smaller projects (which he defines as 120 hours or less). It's basically a spreadsheet with tasks, owners, issues, and deliverables----in essence combining a task list, issues list, and RAM (responsibility assignment matrix) in one document.
It's not a bad approach for keeping the smaller projects under control, and is an effective way of keeping track of things. I'd still use it within the context of a high level framework, but overall it's a good idea. Check it out...
A Small-Project PlaybookLabels: action, it-project, small-project