Project WBS: Product or Task?

With social networking solutions evolving rapidly, the reality is: you're going to be doing this again and again. You're not going to deploy one wiki/document management/discussion forum/... solution that will last for the next five years. So here's the project management challenge: estimating the next effort. To accurately estimate the next effort you're going to need to track actuals for your current effort, and to do that effectively, you'll need a good WBS structure. So do you use a task or product oriented WBS? Many WBS' I've seen are task oriented, where they are broken down by planning, analysis, design, development, and deployment. The problem with this approach is - it's not reusable. If I track how long it takes the team to do requirements analysis - so what? Requirements analysis for the deployment of an integrated suite of commercial (COTS) tools is way different than deploying a home made wiki tool. But, if we track how long it takes to do a wiki tool, whether it be home made, COTS, etc., then we have something we can reuse and compare. And that's why you should use a product oriented WBS, instead of a task oriented one. Large IT organizations can often have planning and estimating groups. I'm not sure why it is, but some of these groups can resist the use of product oriented WBS. This makes estimating almost impossible for later projects. Push for the use of the product oriented WBS, it'll make your life easier later when you have to redeploy part of your collaboration solution. And you will be doing this again!