A WBS is abbreviation for Work Breakdown Structure, and is a hierarchical division of the project into smaller pieces of “work”. The problem with “work” is that it is ambiguous, in that it could both represent an activity or the result of activity (see http://www.merriam-webster.com/dictionary/work).
Most definitions state that a WBS is “product-oriented” (e.g. NASA, MIL-STD-881C, DEF(AUST)5664), although there are also other definitions out there, such as “deliverable-oriented” (e.g. PMI Practice Standard for WBS, Wikipedia). This means that “work” in the WBS should be thought of more as the result of activities, rather than the activities themselves.
Why the focus on products/deliverables?
The focus on products or deliverables ensures that the WBS focuses on WHAT to do rather than HOW to do it. This gives room for those responsible for the deliverable to choose the best way of delivery, for example buying an off-the shelf solution instead of developing it in-house.
A deliverable-oriented WBS also makes it easier to define quality requirements for each specific sub-deliverable. Deliverables also provides more meaningful control of the progress of a project, as completing activities does not necessarily result in the completion of the final deliverables, and in the end it is only the completion of deliverables that is desired.
Some drawbacks of products/deliverables
Not all projects results in a physical product, such as organisational change projects. It is hard to argue that an improved effectiveness of an organisation is a product or deliverable. Therefore it can be useful to think about a WBS as a breakdown of the results of all activities.
Another drawback of the deliverable focus is that it can be hard to estimate the total costs of a project solely on the WBS, without describing all activities required to produce those deliverables. Having the activities in a separate document increases the complexity of managing the project.