Risk-Based Process Tailoring

by NEIL POTTER

As processes become more detailed, it is likely that not all process steps will be needed for all situations. This is particularly true for development life cycle process documents that go into detail about the activities within each major life cycle phase. In order to avoid becoming overwhelmed by the process tasks described, tailoring guidelines are needed. They help the reader determine the activities required for different project situations.

For example, suppose the process tasks for developing a project estimate were:

Estimation Process

1. Develop a Work Breakdown Structure (WBS) for the software requirements
   Purpose: To break down the work into smaller elements and group them by outcome.
2. Conduct a team estimation method (for example Wideband Delphi) on the WBS
   Purpose: To get team input in a controlled fashion and develop a detailed task list, set of assumptions, and estimates for a WBS, or component of a WBS.
3. Use the historical database to verify the estimate for each task
   Purpose: To search the organization’s historical data to see if a similar task (or group of tasks) exists so that previous experience can be used.
   

Executing all these process steps may be appropriate when the project estimate is critical. In such circumstances, any error may lead to a loss in income or severe penalty charges for late delivery. For other projects, performing this level of estimation for every component of a project may not be necessary.

Tailoring guidelines help the reader determine what steps to omit and to understand the corresponding risk. In the example below, tailoring information is described by three additional sections for step 3: Tailoring guideline, Risk if omitted, and Minimum Requirement.

Below is a different example of process tailoring for a software testing process. The table contains a list of test tasks that a project may read in a default process description. Tailoring considers the risk or impact of not performing that activity.

From the table below, one can see the final tailored process (the decision column) and also evaluate the overall risks of omitting some of the process steps. In this example, the project risks related to tailoring the process are:

• All scenarios of code execution are not tested.
• 40% of the code may not be verified to execute correctly. Later conditions may cause untested code to be executed.
• Product may fail during heavy customer usage and with large databases (greater than 88MB).

=========================

Estimation Process

(Step 3 with tailoring guidelines)

Use the historical database to verify the estimate for each task

Purpose: To search the organization’s historical data to see if a similar task (or group of tasks) exists so that previous experience can be used.

Tailoring guideline: This step should be performed whenever applicable data exists. It can be discarded when a new language or technology is being used.

Risk if omitted: Failure to use the database could result in significant oversight about schedule estimates, and could lead to a loss in revenue.

Minimum requirement: Data that exists, but is not considered applicable for the current estimate, must be reviewed with one other manager to verify non-applicability.

=========================

As experience is gained regarding the benefits and problems of tailoring process steps, lessons learned can be factored into the tailoring risk of omission column.

Software Testing 

#	Process Step	Risk if Process Step is Omitted	Process Tailoring Decision (by project team)
1	Unit/module black-box (functional) testing.	The component may not work. Difficult to locate module-level problems during system test.	Test all modules.
2	Unit/module white-box testing (all paths through the module).	All scenarios of code execution are not tested.	Omit. Too expensive for release 1.0.
3	Module interface testing.	Data may not get passed correctly between modules. Difficult to locate module-level problems during system test.	Perform all interface tests.
4	Coverage testing: X% of the code.	(100-X)% of the code may not be verified to execute correctly. Later conditions may cause untested code to be executed.	Perform 60% coverage (include all critical code and most-used code).
5	Load testing (extreme volume of data).	Product may fail during heavy customer usage and with large databases.	Perform load testing to 88Mb.