Transitioning to Level 4

Process Performance Baseline

A process performance baseline (PPB) documents the historical results achieved by following a process. Once a PPB is developed, it is then used as a benchmark for comparing actual process performance in a project against expected process performance.

Exhibit 1 shows an example of a PPB containing the historical productivity results from executing the process used for new development within an organization. There are PPB elements for each of the five phases that this organization has in its life cycle: Requirements Definition, Design, Implementation, Integration, and Systems Test. Implementation for the example organization includes both the classic code and unit test of a software system, plus implementation of individual non-software components . The first line under Requirements Definition is the number of hours to define a complex requirement. There are elements for complex requirements, nominal requirements, and simple requirements with values for the upper limit, mean, and lower limit for each. The Design PPB elements are based on requirements and follow the same structure. Implementation, Integration, and Systems Test PPB elements are based on the work products most important to those phases.

In addition to productivity for new development, an organization would want to develop additional PPBs covering other processes, for example, productivity for maintenance. In addition to productivity, other important organizational goals (e.g., product quality and schedule) would be covered in separate PPBs.

This example PPB points out one of the most important issues with using measures, particularly with using measures at higher maturity levels that is, the need for clear definitions of measures. In this case, what the organization means by a complex requirement, a nominal requirement, and a simple requirement must be clearly defined so that the people collecting the data can tell how to count them. Most organizations start with a working definition and refine the definitions over time. In addition to defining what a requirement is, you also need to define what is included in the number of hours is it only hours sitting at your desk writing a requirement? Does it include hours for attending status meetings to discuss your work? How do you count time for review of requirements? These are questions that need to be answered in your organization to ensure that the data are collected consistently.

So how do you use a PPB with your projects? New projects could use the example PPB for estimating their effort based on estimates of the number of requirements, number of interfaces, number of design pages, etc. The range of values (upper, mean, and lower) allows the estimators to determine the most likely, worst-case, and best-case estimates of not only productivity, but also the staffing levels that are needed.

We have personally witnessed the positive change in organizations when they have PPBs that people believe. The estimation and planning process becomes much more of a professional activity and less emotional. Project managers armed with PPBs based on historical process performance are less likely to fall victim to unfounded pressure to lower estimates and reduce schedules.

After planning, the PPB can also be used to monitor and control the project's work by comparing the actual number of hours to perform the work against expected range of values for the PPB element. Remember: if the actual number of hours is outside the expected range, it is only meaningful if your process is already stable. Stabilizing your process takes time. Look for the cause but do not overreact. Your process may have a lot of variation, and the tendency early on is to shoot the messenger. If people believe that bad things happen to people when the data are not what is expected, the people will find ways ( devious and nefarious ways) to make the data acceptable. This is not what you want.