When we start working at a project we are very focused on the process that we follow. For most of IT projects following waterfall model, phases of the project are quite the same. Requirements, Design, Development, System Testing, Acceptance. Even in large projects, we have a time sequence in forms of iterations, phases and within each phase we follow similar patterns.
Estimations are done before hand based on the high level requirements. Which get refined after the details of requirements in first phase are done. But rarely adjusted for actual work. Glen Alleman writes about confusion between effort and results. This is a good article which explains how to move the focus from effort to actual delivery of the project. What he suggests is to create the WBS based on completing a requirement rather than for a phase of the project. One of the advantage of this is that you can actually get a pretty good view of how much work you have really completed. This also helps you work out the dependencies between various features.
My experience with project management suggests use of UML for requirements management. I used Enterprise Architect UML modeling tool for the same some time back. One of the great use of this tool is to be able to model the requirements and be able to map them with actual code components. This gives us a clear traceability between various components and requirements. So when a change in system is required it is much easier to find the impacted areas.
However, I do not agree with some of the exclusion Glen speaks about. Some WBS activities are required to ensure that the product is delivered and the people issues are also well taken care of. We do need to have a holistic view of the product in the early work. We can not break the WBS in set of features before we have addressed some key architectural issues. Also the tooling required for the project is indicated by the design. If the tool has a wider effect on the project, it needs to be considered in the WBS. But apart from these all other points are very valuable for delivering the product.