The term “business process management” (BPM) is often encountered in conjunction with Six Sigma and Lean initiatives. Typically it refers to identification of core business processes, assignment of process ownership and definition of measures (and perhaps benchmarks) that indicate the health of a particular process. These measures are often influential in selection of Six Sigma or Lean projects.

Ideally, processes are defined in a way that is independent of the specific organization structure used to execute those processes. Hence, they are best described in terms of what is being done – without regard to who or how – in a solution-free, action-verb form.

Though BPM is less frequently encountered in software development organizations, it can be equally powerful as a guide to identification and prioritization of improvement opportunities in software companies.

Core Process in Software Development

Software development processes may be grouped into two process areas – lifecycle processes (analogous to core business processes) and cross-lifecycle processes (analogous to supporting business processes).

Primary lifecycle processes in software organizations might be described as follows:

• Discovering requirements
• Designing solutions
• Constructing solutions
• Validating solutions
• Implementing (or deploying) solutions
• Supporting deployed solutions (including defect repairs, minor enhancements, changes dictated by evolution of underlying technologies)

Primary cross-lifecycle processes typically include:

• Planning projects
• Estimating (or forecasting) effort, duration, delivered quality
• Tracking and reporting status
• Defining processes and standards
• Measuring and monitoring process performance
• Training
• Controlling versions and releases of software work products (configuration management)

Process Measures in Software Development

Performance of all software processes can be appropriately characterized by some combination of the following metrics:

• Cycle time (calendar duration)
• Defect rate
• Effort (person-days or hours)
• Size (e.g., function points, lines of code or any other suitable proxy measure)
• Capability – A measure of the efficiency of a software process (e.g., Putnam’s “Productivity Index” [Five Core Metrics by Lawrence H. Putnam and Ware Myers])
• Schedule pressure – The schedule itself has been shown to be a significant X when estimating effort and the schedule required to process a given size through a process with a given capability.

Essentially, the software development dashboard or scorecard boils down to a set of measures that answers three questions for each process:

• How long does it take (in relation to size) (i.e., cycle time, throughput)?
• What does it cost (in relation to size) (i.e., effort required, efficiency)?
• How good are the products it produces?

Answering these questions in a meaningful way requires the use of compound measures that qualify conclusions in relation to factors known to be influential. The following table illustrates contents of a dashboard that succinctly provides answers to the above questions.

Table 1: Illustration of Contents of Dashboard
Process	CycleTime	Defect Rate	Effort
Discovering Designing Constructing Validating Implementing Supporting Planning Estimating Tracking Defining Measuring Training Controlling	Duration/size Not applicable   Duration/size	Defect containment rate adjusted for schedule pressure Internal change rate (not driven by requirements changes) Actual versus estimate, adjusted for changes in size Not applicable Post-deployment change rate ? Defect rate	Effort/size, adjusted for schedule pressure; total rework; appraisal cost total and per defect Not applicable Effort/size ? Effort/size

While there are potentially additional measures that may be of interest, any organization that has all of these is certainly far ahead of the pack.