Most of the time, I whole-heartedly agree with Joel's points. However this time around, I had to disagree with him on the whole notion of Beware of Methodologies. I worked in one of those companies which these methodologies are created and taught. It is a great way to standardize the lingo across geography and a diversed workforce. After studying the methodologies and the tools around, it is pretty clear to me these were written by some very smart people. One of those tools I am glad I got a chance to used is the estimators.
Even though the estimators are written in, god forbid, excel and vbscript, the out-come of the tools was a excellent framework to work within to estimate projects. Each field has their own estimator and each estimators are different. No doubt some are better the other, nonetheless it is one way to put structure into the art project estimation which I argue even the most talented programmer, project manager or genius can gain some benefit from.
I want to emphasize this one more time: these methodologies and tools are merely framework or guidelines. I.e. if the methodologies list any deliverable which doesn't make any sense for your particular project, document exactly why it doesn't make sense to do it, and don't do it. The estimator is even a better example of this. In the custom application development estimator, it list every activity in the custom application development methodology. In the custom application development methodology, it list every activity in custom application development known to man-kind. By default, after you enter all you inputs to the estimator, the estimation is going to be insanely huge! This is normal. The next step in the estimation phase is to go through the tasks, assess the client's needs, and rationalize their needs against the tasks. Scale back the task estimation if it is too had, drop it if it is not needed. Bottom-line, work with the client and document the decisions on scaled-back or drop task.
More often than not, even the smartest person cannot forsee everything, or he/she assume it does not need to be done. It is often the aggregation of a missed task here, a wrong assumption there which cause consulting projects to fail. In other words, these methodologies enable people to learned from other's past experience.
Don't get me wrong, these methodologies are by no means perfect. In my opinion, these methodologies are a great framework to work within. The problem is not the tools or methodologies itself, but the people using them. The not-so-talented people often treat these tools or methodologies as the "Silver-bullet". Instead, they are merely guidelines or frameworks which one could work within. It is not an end, but merely a mean to achieve the end result desired.
After all, it is garbage-in garbage-out and there is no black-magic or cure for that.