Page 107 -

6 - PROJECT TIME MANAGEMENT

Software schedules are frequently revised. Unscheduled prototyping and code experimentation may be needed
to support decision making. These activities may not be identified during initial scheduling, so the ripple effects
they cause can impact sequencing of other activities. Rework to fix discovered defects is another activity that may
not be anticipated but is necessary for successful project completion. This unanticipated work (sometimes referred
to as dark matter) can often take precedence over other work and is sometimes tracked independently. Section
6.7 of this Software Extension describes the role of burnup and burndown charts in relation to scheduling issues.

Adjustment to schedule sequencing for adaptive life cycle software projects is more dynamic and typically occurs
more frequently than for predictive life cycle projects; adaptive scheduling generally provides more opportunities
to absorb unplanned work. A schedule plan is created to provide structure for the adaptive iterations, their content, 6
and any points in time for release of intermediate versions of the final software product. However, the plan is
revisited often to incorporate changes related to feedback based on factors such as demonstrations of the evolving
product, productivity (velocity) data, unscheduled work, and retrospective findings.

Managers of adaptive software projects usually schedule the sequence of work activities prior to the start
iterative development but, as stated, the scope of this initial sequencing is typically refined as the project evolves.
In some cases, higher levels of features and story breakdowns are used to coordinate lower levels—with the
unscheduled work absorbed into the estimates for the higher-level activities.

On-demand scheduling techniques allow the work to flow to whatever suitable staff resources become
available. This is sometimes referred to as late binding of the work to the available resources. The available staff
resources dynamically select (or are assigned to) the next work to be done based on value added of the queued
work activities. Value is defined by project specific risks and constraints (e.g., cost of delay, value to customer, class
of service, or criticality of service).

Rather than date-certain scheduling of events or a specified time box when a certain number of tasks are to be
completed, on-demand scheduling establishes a regular cadence of events, such as completion of demonstrable
increments of software. The pace of the cadence is determined through measures such as velocity or statistical
based lead-time or transit time for an activity. The cadence then provides an indication of how long a customer
or software project manager can expect to wait for a particular activity to be completed. Work-in-progress limits
are used to maintain resource viability and to smooth out workflow; these are adjusted according to statistical
measures maintained throughout the development process. Visual indicators (i.e., workflow charts) can be used to
provide visibility and help identify and resolve bottlenecks to make better use of available resources.

6.3.1 Sequence Activities: Inputs

The inputs in Section 6.3.1 of the PMBOK Guide are applicable inputs for sequencing software project activities,
®
with the modification of 6.3.1.7 and extensions of 6.3.1.8 and 6.3.1.9 (see below).

6.3.1.1 Schedule Management Plan

See Section 6.3.1.1 of the PMBOK Guide.
®

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