16 Tailor the Standard Process

A defined software process provides organizations with a consistent process framework while permitting adjustment to unique needs.

—Watts Humphrey

In the automobile industry, standard vehicles are produced and then sold to individuals with added features known as options. Options, in other words, provide adjustment to individual preferences. Together, standard vehicles and options reduce the risk of producing cars and selling them to different people. Standard vehicles promote the economies of scale necessary for mass production; options provide the features that increase sales and customer satisfaction. Options are paid for by those who desire them.

Similarly, in the software industry, standard processes are defined and then used by projects with minor modifications. We refer to these modifications as tailoring options. Tailoring provides the flexibility required to modify a standard process to adjust for differences among projects. Together, a standard process and tailoring options reduce the risk of developing software that must satisfy different requirements. The standard process provides a common understanding of processes, roles, and responsibilities; tailoring provides the advantage of flexibility for disparate projects.

The purpose of tailoring the standard process is to define the risk management process for a specific project. Unique aspects of a project are addressed, such as size, budget, and organizational structure. Tailoring the standard process involves reviewing the organization’s standard process and recommending changes to fit a cost-effective process for a particular project. Deviations from the organization’s standard process are documented as waivers. The defined risk management process is peer reviewed, documented, approved, and distributed to the project team.

In this chapter, I provide suggestions for tailoring the standard process to custom-fit a particular project. I list the ways in which a project could be considered unique and provide a form for recommending deviations from the standard process based on the unique aspects of the project.

This chapter answers the following questions:

Image What are the steps to tailor the standard process?

Image Why is there a minimum standard risk management process?

Image What factors can you use to differentiate risk management on projects?

16.1 Review the Standard Process

A defined software process should provide a minimum standard process and tailoring suggestions [Humphrey89]. A minimum standard risk management process provides a common set of metrics that enable project comparisons. At the organizational level, project comparisons provide visibility into progress so that intelligent decisions can be made. Allocation of staff resources among projects is one such decision made at the organizational level. The minimum standard process can be visualized as a process kernel, with the kernel defining the areas that need to be standardized to leverage knowledge between projects. The activities performed within each process can vary between projects if standardization occurs at the process output. The following risk management process outputs should be standardized:

Image Risk statement. The standardization of how to communicate a risk can promote understanding between the project team and the rest of the organization.

Image Risk list. The format of a risk list that shows the key issues facing a project can help management see common themes to address on all projects.

Image Risk action plan. The attributes of an action plan should be consistent, to promote completeness and reuse of successful plans across the organization.

Image Risk measures. The standard definitions of risk measures enable organizational risk metrics and consistent communication to senior management.

Image Risk database. The project risk database should easily merge into an organizational database to retain lessons learned in corporate memory.

16.2 Examine Tailoring Options

After you determine the minimum standard part of the process that cannot be compromised, examine your tailoring options. Recommendations for tailoring are often defined in the standard process. Several tailoring suggestions are made for each process element in Table 16.1. Examine the options listed for each process element to understand some possible process modifications.

Table 16.1 Process Tailoring Options

Image

16.3 List Unique Project Factors

How will you decide among all the options for customizing the risk management process? Base your decision on an understanding of the unique aspects of your project. In general, high-risk projects need a more rigorous process.

Three factors used to differentiate risk management on projects are most important:

Image Size. Your risk is low if your project size is small (fewer than ten people).

Image Budget. Your risk is high if your budget is tight or your contract is fixed price.

Image Structure. Risk increases as a function of the number of interfaces within the project organization structure. Your risk is high if your project has no organization chart that defines the channels of communication.

There are other factors as well that can be used to differentiate risk management on projects:

Image Life cycle model. If your project life cycle model is the Grand Design (a doeach-step-once strategy), your risk is high that you may not understand requirements well enough to deliver all capabilities at once. If the model is Incremental (a strategy that adds functionality to the existing system), your risk is high if your requirements are unclear or you expect rapid changes in mission technology. If the model is Evolutionary (a strategy that iteratively refines the total system), your risk is moderate if your user prefers all capabilities at the first delivery [DoD95].

Image Software development process. If your project does not follow a documented software development process or is a new process, your risk is high.

Image Level of automation. Your risk is high if your development tool set is new or not integrated throughout the life cycle. A lack of automation on large systems is also high risk.

16.4 Recommend Process Changes

Project personnel can optimize their risk management process by recommending process changes that provide the following enhancements:

Image A better process is preferred because it is more suitable to the project needs. For example, a method may be preferred because it is familiar and will not require time for training.

Image A faster process takes less time to implement. For example, an automated tool might expedite the process.

Image A cheaper process is reduced in cost. When a process is economical, the return increases.

If your project has a subcontract, it is to your advantage to share your project’s risk management process. Help your subcontractor understand what aspects of the process are standard and what may be tailored. Your partnership in managing risk will ultimately reduce project risk.

16.5 Document Standard Process Deviations

You should obtain a waiver for deviations from the standard risk management process. A waiver form—one is shown in Figure 16.1—is a mechanism to help projects customize standard processes. The time spent in negotiation and compromise up front is better than implementing a time-consuming process that is not suited to your needs. It is easier to refine a plan than it is to implement a bad plan. Approved waiver forms help to promote support and commitment from the organization management. For example, a tailored risk management plan should be reviewed by quality assurance and approved by the project manager and functional manager. Highlighting changes from the standard process on a waiver form will assist these activities.

Figure 16.1 Waiver form. Deviations from the standard process are approved by project management using a standard process waiver request form.

Image

16.6 Summary

In this chapter, I provided suggestions to tailor the standard process to custom-fit a project. The steps to tailor the standard process are as follows:

1. Review the standard process.

2. Examine tailoring options.

3. List unique project factors.

4. Recommend process changes.

5. Document standard process deviations.

There is a minimum standard risk management process to leverage knowledge between projects and enable project comparisons. The activities performed within each process can vary between projects if standardization occurs at the process output. The following risk management process outputs should be standardized:

Image Risk statement.

Image Risk list.

Image Risk action plan.

Image Risk measures.

Image Risk database.

I listed the ways in which a project could be considered unique. The following factors can be used to differentiate risk management on projects:

Image Size.

Image Budget.

Image Structure.

Image Life cycle model.

Image Software development process.

Image Level of automation.

16.7 Questions for Discussion

1. List three ways that tailoring options increase the flexibility of a standard process.

2. What are the benefits of a minimum standard risk management process?

3. List five outputs of the risk management process that you should standardize.

4. Give an example of a tailoring option for each process element of the risk management process.

5. Discuss three factors that you can use to describe your project’s need for risk management.

6. You are responsible for tailoring the standard risk management process for your project. What is your process for determining your recommendations?

7. In what ways do you consider your current project to be unique?

8. Discuss what might happen if you could not tailor the standard process.

9. List five reasons that you should document the proposed deviations from a standard process.

10. Do you think a defined software process should permit adjustment to unique project needs? Discuss why you do or do not think so.

16.8 References

[DoD95] Department of Defense. Guidebook for MIL-STD-498 Software Development and Documentation Overview and Tailoring. Philadelphia: Defense Printing Service, 30 January 1995.

[Humphrey89] Humphrey W. Managing the Software Process. Reading, MA: Addison Wesley, 1989.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.227.26.217