If I understand the question, I guess it's something I do every day (all day sometimes). First, I need to have a set of working parameters. Preferably, I have some of the most painful parameters, the ones that cause the most work or return the most data. Assuming I have them (I can get them by using Profiler, but let's not go there for the moment), I always start with an execution plan (shocking I'm sure). In addition, I get the Statistics I/O and TIME. Usually, these three bits of information are enough. But if you get into really tough procedures, you might go back to Profiler and set up a trace that captures statement executions (I've been doing a bunch of that this week on a particularly ugly query I was tuning). This will show which statement within the query is causing pain. If you're really stuck, you should also capture wait states to see what specifically is causing the slow down (this week it was I/O latches caused by fragmented indexes, I'm beating, uh, I mean talking to, the admin team about the missing defrag job).

Is that the sort of thing you're looking for? Obviously I'm skipping hundreds of details on every step.