Editing Work breakdown structure (section)

===Plan outcomes, not actions===
If the work breakdown structure designer attempts to capture any action-oriented details in the WBS, the designer will likely include either too many actions or too few actions. Too many actions will exceed 100% of the parent's scope, and too few will fall short of 100% of the parent's scope. The best way to adhere to the 100% rule is to define WBS elements in terms of outcomes or results, not actions. This also ensures that the WBS is not overly prescriptive of methods, allowing for greater ingenuity and creative thinking on the part of the project participants. When a project provides professional services, a common technique is to capture all planned deliverables to create a deliverable-oriented WBS.<ref>Swiderski, Mark A., PMP [https://www.workbreakdownstructure.com/work-breakdown-structure-according-to-pmbok.php workbreakdownstructure.com], PMBOK-Work Breakdown Structures. Accessed 16. June 2013.</ref> Work breakdown structures that subdivide work by project phases (e.g. preliminary design phase, critical design phase) must ensure that phases are clearly separated by a deliverable also used in defining entry and [[Exit-criteria|exit criteria]] (e.g., an approved preliminary or critical [[Design review (US Government)|design review]]).

====Product breakdown structure (PBS)====
For new product development projects, the most common technique to ensure an outcome-oriented WBS is to use a [[product breakdown structure]] (PBS).

====Feature-driven development====
[[Feature-driven development|Feature-driven software projects]] may use a similar technique as the WBS, which is to use a feature breakdown structure.