Page 461 - Design for Six Sigma for Service (Six SIGMA Operational Methods)

Theory of Constraints 419

discovery of a policy constraint. Many times, a policy constraint is often
mistaken as a resource constraint. Example 12.2 gives a very common
policy constraint in the software development process.

Example 12.2: A Policy Constraint in Software Development
Many software companies suffer from long product development time and cost
overruns. On the surface, many of these problems appear to be caused by the
shortage of labor and resources. These bottlenecks delay the software release
time to the market, so they directly reduce the throughput. However, many
researchers indicate that most of these constraints are actually policy con-
straints. One very common policy constraint is the practice of multitasking, that
is, where one programmer is involved in many software development projects
simultaneously. If the programmer is involved in too many projects, then mul-
titasking can delay the project completion time, so this practice is often a policy
constraint. The following examples show how multitasking practice can delay
the software project completion times.
Figure 12.4 shows three software development projects. Each has 10 modules,
that is, module A through module J. Assume each module needs 2 weeks to be
completed and that each project will take 20 weeks. However, in these three
software development projects, there are three types of modules. Modules A, B,
and C are type-1 modules and need to be written by one type of programmer
(resource 1); modules D, E, F, and G are type 2 and need to be written by
another type of programmer (resource 2); and modules H, I, and J are type 3
and need to be written by yet another type of programmer (resource 3). The
company only has one programmer for each type, so these three projects cannot
be done as described in Fig. 12.4. So the company can use the multitasking
approach described in Fig. 12.5, in which each programmer (resource) is
involved in all three projects simultaneously and switches between projects all
the time. We can see that each software development project will take from
48 weeks up to 52 weeks to finish with the multitasking approach.

Figure 12.6 shows a nonmultitasking approach; each programmer is involved
in one project at a time. We can see this approach actually reduces the software

Project 1 A B C D E F G H I J 20 weeks Resource 1

Project 2 A B C D E F G H I J 20 weeks Resource 2

Project 3 A B C D E F G H I J 20 weeks Resource 3
Figure 12.4 Three Software Development Projects