Page 84 -

5 - PROJECT SCOPE MANAGEMENT

Iterative development cycles and development of product increments can be used during the software
construction stage of both predictive and adaptive software projects. The scope of requirements or features that
can be implemented during an iteration cycle is determined by the specified time period (the time box) and the
production rate of the development team. The production rate can be based on accumulated experience using
measures such as velocity and burndown rate when the time box and the number of team members are fixed
from iteration to iteration. Short-duration development cycles provide rapid feedback and the ability to revise
and reprioritize the product scope based on demonstrations of tested working software; this may be easier to
accomplish for adaptive life cycle projects than for predictive life cycle projects. 5

Another aspect of iterative development that develops product increments on some of the iterative cycles
(perhaps all) is the learning environment in which customers and users clarify and prioritize requirements and
product features based on value-adding priorities and periodic demonstrations of working software.

5.4 Create WBS

The inputs, tools and techniques, and outputs for Create WBS in Section 5.4 of the PMBOK Guide are equally
®
applicable for creating work breakdown structures for predictive life cycle software projects. Comparable techniques
for adaptive software projects are described in Section 5.4.2.5 of this Software Extension.

Section 5.4 of the PMBOK Guide includes the following statement: “In the context of the WBS, work refers
®
to work products or deliverables that are the result of activity and not to the activity itself.” The PMBOK Guide
®
distinguishes between organizing a WBS by phase or by major deliverables at the second level.

For software projects, the top level of the WBS subdivides the project by life-cycle process or activity. The work
products and deliverables are shown as outputs of activities and tasks at lower levels in the WBS. This form of WBS
is referred to as an activity-oriented WBS (Section 5.4.2.3 of this Software Extension provides an example).

Activity-oriented work breakdown structures are desirable for most software development projects because
software is the product of the cognitive processes of software developers and does not involve fabrication of
physical work products or deliverables in media such as wood, metal, plastic, or silicon. Work packages for the
tasks in a software WBS include specification of the work activities and the work products or deliverables to be
created or modified by those work activities, as well as the acceptance criteria for the work products or deliverables.
Activity-oriented work breakdown structures are also applicable for other kinds of knowledge-based work.

Considerations for developing an activity-oriented WBS for a predictive life cycle software project can proceed
top-down as follows: (a) by first specifying the project activities at the top level and decomposing each top-
level element into subordinate activities and tasks; (b) by first identifying the lowest-level tasks to be performed
and grouping them into successively larger groupings (activities); or (c) by working “middle out” by identifying
intermediate-level activities and decomposing them downward and grouping them upward. In practice, all three
approaches are typically used to produce an activity-oriented WBS. Predefined templates for work breakdown
structures and work packages, plus examples designed to fit the local situation, make the task of constructing a
software WBS much easier than starting without guidance.

©2013 Project Management Institute. Software Extension to the PMBOK Guide Fifth Edition 73
®