9 Develop the Policy

Sometimes if you want to see a change for the better, you have to take things into your own hands.

—Clint Eastwood

It is easier to turn the wheel of a car when it is in motion. An organization is no different from a car when it comes to changing directions. The key to a faster response to change lies in the ability of the organization to have forward momentum.

Software organizations have had (and will continue to have) many changes—for example, new distribution channels over the Internet, relaxed government software standards, and increased competition due to globalization of the workforce. We cannot react easily and swiftly if we have not established the direction for our organization. To set an organization in motion requires the development of policy, an administrative order that sets the direction for the organization. It is policy, not process, that starts an organization on the path to institutionalizing a behavior. Policy is determined at the highest level in the organization. A top-down approach ensures that policy is important enough to allocate resources to it. It is what the administration expects the organization to follow.

In this chapter, I provide a risk management policy, which is designed to help you develop a risk ethic within your organization. I describe how to establish a firm foundation for managing risk by developing a strategic plan to institutionalize risk management.

In this chapter, I answer the following questions:

Why is a risk ethic important to an organization?

What does a risk management policy contain?

How does policy set expectations for project behavior?

9.1 Obtain Commitment

To obtain the commitment required for organizational change to risk management, the need for and benefit of a risk ethic must be communicated.¹ A risk ethic is the rules of conduct that characterize a proper risk management philosophy. The central theme of the philosophy is the notion that risk is the organization’s responsibility. A risk ethic follows from this philosophy as a set of behaviors appropriate for handling risk at work. The doctrine of the risk ethic supports the following rules:

¹SEI describes a risk ethic as involving everyone in a continuous process of identifying, communicating, and resolving risks in an open and nonthreatening environment [VanScoy92]

Take responsibility for risk.

Do not blame people for risk.

Communicate risk to the right people.

Be proactive in managing risk.

Learn from unexpected outcomes.

The need for a risk ethic can be substantiated by the challenges facing the entire software industry. The general problems the organization faces also support the need to manage risk. Instances of missed opportunities, such as proposals that were lost to the competition, can point to a need to strengthen risk management practices. Specific surprises on projects that could have been avoided also show the need for increasing the ability to manage risk. Communicating the needs is a matter of documenting and sharing both general and specific areas where risk management can help people work better.

The benefits of nurturing a risk ethic are demonstrated by organizations that have achieved success through diversification and individual responsibility. The open communication of risk helps an organization to resolve risk, avoid problems, reduce rework, and provide focus.

Obtaining commitment is the first step in developing a policy for risk management. Commitment is demonstrated top-down when the administration allocates resources to a task and bottom-up from the employees who support the task. Change occurs when there is both top-down and bottom-up commitment; one without the other will not suffice. As shown in Figure 9.1, institutionalization depends on the level of commitment over time [Fowler93]. Commitment, not interest, is what it takes for long-term success in changing or developing an organizational culture. When we are interested in something, it can hold our attention for a time until we find something else to take its place. When we are committed, we understand that it is our duty to see the task through to completion. Interest will wane over time; commitment strengthens as progress is made toward goals. Early on, commitment is based on trust and faith that the goal is worth the effort. Closer to the goal, our commitment is based on knowledge and understanding that we did the right thing.

9.2 Allocate Resources

To set a car in motion, fuel and a driver are required. Leaders of the organization are the drivers of policy. To be a leader, you do not have to be on the senior management team. If you see a need within the organization, you can enlist the support of key opinion leaders and influence those at the top. Sign petitions, make telephone calls, and send letters to make your concerns known. Anyone, at any level of the organization, can be a leader. If you are not currently in a position of influence, you need to know that the senior management team would probably welcome your ideas and energy.

Figure 9.1 Phases of the learning process. Institutionalization is the result of a learning process that requires increasing levels of commitment over time. (Source: [Fowler92])

Resources are the organizational fuel that is needed to develop policy that sets the organization in motion. Personnel resources—needed to survey the existing practices, obtain the commitment for the policy, define the policy, and communicate it to the organization—must be budgeted and scheduled. People accomplish little without time and money. When the administration allocates resources to develop policy, it demonstrates the importance of it to the organization.

I once went to my organizational management and asked for $3,000 to establish a policy and procedure for human factors in software systems. My ideas for the problem, objectives, and team to carry this out were hand-written on one piece of paper. Because I am not trained in human factors, I was not qualified to serve as a member of the team. My leadership was in recognizing a need and asking for the resources to make it happen. My point is that anyone can influence policy, but policy influences everyone.

9.2.1 Apportion the Budget

If you are going to influence everyone through policy, you need money from a budget. Budgets are planned before they are allocated. To find a sponsor for your idea—that is, someone who controls budgets, and therefore money—think about who would benefit from the policy. Engineering managers may support several project managers and understand the needs of their projects. Directors may support use of their budget to help several projects and proposals in their business area. General managers may have an entire division that would benefit from a policy on risk management. Once a source of money is found, you must sell your idea to the sponsor. Briefly state the cost and benefits to the sponsor. Justify your statements using a few facts with your enthusiasm for the task of developing policy and ensuring its success into implementation to serve the organization better. Close by asking for a specific amount over a specific time period. If money cannot be allocated from the current budget, ask the sponsor to place a line item for this task in the next budget.

9.2.2 Apportion the Schedule

The schedule bounds the time for each activity required to achieve the objectives. The schedule will be dependent on the amount of money received from the sponsor. Funding may be incremental, and activities should be scheduled to show progress at each increment. Figure 9.2 shows the dependencies of the activities and the relative time for each activity. The activities should have deliverables such as the documented policy, a standard process definition, training material, and a method to verify and improve the practice. The schedule may show how the process will be piloted on either a small project or a small part of a large project. Time for feedback from the pilot program and incorporating improvements should be scheduled prior to requiring the organization to follow the documented policy.

Figure 9.2 Chart of scheduled activities. The plan for developing a policy and process for software risk management includes allocating resources in terms of budget and schedule.

9.2.3 Assign the Personnel

When it comes to initiatives at the organizational level, it is best to recruit a volunteer team. Talk with people to get an indication of their interest and ability to commit their time to the task. Set the proper expectations of what is required of individuals before they sign up. For example, check that the schedule and meeting time fit the expectations of the individuals. Ask that they discuss the possibility of signing up with their supervisor, to be sure that each team member is fully supported in his or her efforts. Let these people know what they will receive in return: the personal benefits in learning new skills and taking a leadership role within the organization, and celebrating when the objectives are met, such as having lunch with the sponsor. Remember that there is strength in diversity, so be sure to recruit a cross-functional team.

9.3 Survey Existing Practice

The first task of the team in establishing a firm foundation for managing risk is to survey the existing organizational practices. If you are from the software development side of the organization, you will need to check the practices in new business, proposals, other projects, and internal studies. The policy must consider that the practices of implementation will vary depending on the application. As such, the policy is a general statement of the commonality for all applications.

9.3.1 New Business Practices

There is risk in new business, often due to uncertainty in customer demand and the ability to deliver on promises made to customers. Those who work in the marketing department might ask the following questions:

Will sales prices have to be changed to reflect unanticipated demand levels for the product?

Will organizational downsizing affect time to market?

Can the software engineers be trusted to deliver a quality product?

Is project management easier than this job in marketing?²

² Changing jobs is a career decision that requires careful risk analysis.

Chances are that the marketers have methods for dealing with these risky situations. To develop a policy that accommodates new business practices in software risk management, ask several people in marketing how they accomplish their work. Do they run business models on spreadsheets? Do they use customer surveys? How do they track product features of the competition? How do they manage their uncertainty and make decisions with incomplete information? Gather any procedures, forms, tips, guidelines, or tools that they use.

9.3.2 Proposal Practices

There is significant risk in writing proposals. There must be a balance between the resources invested in a proposal and the likelihood of contract award. The bid– no bid decision is probably the decision with the greatest risk that is made during the proposal phase. What could prevent success in winning the contract? Having a risk philosophy enables proposal teams to quantify their chances for success. One proposal team could have saved $3 million and years of effort in preparing a demonstration, if the prime contractor had only assessed their risk early in the proposal. Evidently they thought software capability could be bought by subcontracting the software development to an SEI Level 3 company. The risk that was recognized by the customer (but not the prime, until too late) was the doubt that an SEI Level 1 prime contractor could manage an SEI Level 3 subcontractor.

Risk management can be used as a discriminator throughout the proposal document. Your plan to handle risk intelligently, from using uncertainty to improve the cost model to simulating system performance, will win points. Chances are that the proposal writers have methods for dealing with these risks. To develop a policy that accommodates proposal practices in risk management, ask several people working on proposals how they accomplish their work. Gather any customer-driven requirements for risk management and prior proposal write-ups, especially those from winning proposals. From proposals that were lost, ask the people on the proposal team for lessons learned.

9.3.3 Project Practices

Projects are more likely to have persistent problems than managed risks. Chances are that there are some risk management activities going on. When you survey people who are working on projects, try to capture their terminology. They may discuss risk in terms of potential problems or issues. Do they write down potential problems in weekly status reports? Are issues reviewed at technical staff meetings? Does someone coordinate issues that affect several integrated product teams? When are technical interchange meetings scheduled? Does system engineering track technical performance measures at the software level? How does software engineering prevent problems in meeting specifications, cost, and schedule? By surveying people at all project levels, you will have a general sense of attitudes toward risk. Does the organization push technical capabilities, develop complex systems, or maintain safety-critical systems? Knowing the extent of project risks helps to establish the rigor of the risk management policy needed. Knowing the level of risk management practice helps to provide the training material needed to implement the policy. Gather any documented processes, templates, completed forms, or needs to implement risk management practices successfully. Note too what is missing. For example, people in the organization may need to become aware of tools that support risk analysis.

9.3.4 Research and Development Practices

Internal research and development (R&D) often has different risk management practices from either proposals or projects. All innovation involves a degree of uncertainty [Souder87]. Only by taking a risk can we move forward to learn new things. Ideas by themselves will not make a difference. Experimentation gives ideas the reality required to be practical and useful. By experimentation, we test out new ideas and handle unexpected outcomes. When you have a successful outcome, you have improved something. When you have an unexpected outcome, you have learned something. Treating each unexpected outcome as a mistake is a destructive practice that reduces confidence and inhibits risk taking.³

³ I learned this concept from a videotape titled Risk Taking for Higher Performance, produced by Synectics Corporation in Cambridge, MA.

To develop a policy that accommodates risk management for small studies and laboratory environments, ask several people in R&D how they accomplish their work. Do they have the courage to take a risk when they do not know the outcome? Do they understand that the risk of not taking risks is being left behind? Are they able to embrace their mistakes? Do they own the mistake, examine it, and learn from it? Knowing the attitudes toward risk in the part of the organization responsible for future growth helps you understand the need for education. Gather innovation techniques, experimentation methods, and benefits they have found by managing uncertainty. For example, people in R&D may have benefited by increasing the number of experiments, which actually lowers risk by increasing knowledge and the ability to adapt through trial and error.

9.4 Define Draft Policy

The purpose of a draft policy is to enroll the opinion leaders in the change process. Before a new approach can be embraced, people must let go of the old ways that are no longer effective. People can contribute to shaping the policy by a top-level review of the policy description. They can own a piece of it through their comments and suggestions. Through ownership, people will be more likely to accept the policy and less resistant to it.

9.4.1 Involve the Opinion Leaders

Through involvement, opinion leaders are made aware of a draft policy for risk management. Opinion leaders influence others because they are vocal about their beliefs. Involving them late in the policy definition process is a mistake. It shows that you did not depend on their input but are now asking for their support. It is important to spend individual time with opinion leaders to understand their concerns and prepare to address them. A kickoff meeting can then be held to generate ideas with the rest of the organization.

9.4.2 Outline the Policy Contents

Although the entire policy is subject to negotiation by team members, here is an outline to start with:

Subject: Software Risk Management.

Reference: Standard procedure SP-050-SRM.

Purpose: To establish a proactive approach to managing risk by routinely assessing and controlling project, process, and product risk.

Policy: It is the policy of the XYZ organization that risks will be managed by each employee.

Scope: New business, proposals, projects, and internal research and development.

Objectives: Maximize profit and minimize risk.

Responsibility: Individuals are accountable for identifying risk to their team leaders. Team leaders are responsible for communicating issues that cannot be resolved at the team level to their manager. Managers are responsible for ensuring coordination with affected third parties. The project manager is responsible for ensuring coordination with affected external parties.

Authority: The project manager delegates authority as required to manage risk.

Procedure:

1. Document a risk management plan.

2. Perform a baseline risk assessment early in the project.

3. Report risks at weekly status meetings.

4. Review risks at monthly project reviews.

5. Maintain a risk database, and deliver it at project completion.⁴

⁴ Maintaining a corporate risk database allows reuse of successful risk resolution strategies and a knowledge base of lessons learned.

9.5 Review Draft Policy

Circulate the draft with plenty of time for busy people to review the policy and prepare their comments. Host a meeting where people bring changes, and discuss the issues. The policy review should promote understanding of the risk management practices expected within the organization and result in incorporating the feedback of the people who will be practicing risk management to obtain their concurrence. Use a consensus process to ensure that everyone can live with the draft policy.

9.5.1 Promote Understanding

Limit the policy to one page. The advantage of a single page is that more people will read it, the intent will be clearer, and the direction will be limited to allow for a flexible implementation. Standard terminology should be used in the draft policy. For example, if the term shall is too formal for your organization, do not use it. If the project manager is called principal investigator on internal research and development, then incorporate that language so that the policy will speak to all affected individuals. Be sure to define and agree on all the terminology. Establishing a common vocabulary within the organization is the most important aspect of the policy.

9.5.2 Incorporate the Feedback

The personnel assigned to develop the policy are responsible for incorporating changes. All changes should be consistent with respect to the intent and vocabulary of the policy. It is appropriate to thank those who contributed comments and perhaps provide an explanation to anyone whose suggestion was not incorporated. After changes are made, you may want to post the draft policy on a bulletin board to show work in progress.

9.6 Document Policy

The policy should be documented in a standard format and incorporated in a manual of operating procedures. A hard copy should be available at a specific location, such as the personnel department. It is also helpful to have this in soft copy for employees to browse on-line.

NASA policy objectives with regard to project risks are expressed in the NASA Systems Engineering Handbook [NASA95]. Section 4.6 of the handbook references the following risk management policy (NMI 8070.4A):

Provide a disciplined and documented approach to risk management throughout the project life cycle.

Support management decision making by providing integrated risk assessments (i.e., taking into account cost, schedule, performance, and safety concerns).

Communicate to NASA management the significance of assessed risk levels and the decisions made with respect to them.

9.7 Approve Policy

The policy should be approved at the highest levels to ensure that senior management agrees with the changes from the policy review. This approval should include the signature of a senior manager who represents the management team. Commitment from the top sets expectations for project behavior.

9.8 Communicate Policy

The policy should be communicated to the organization in a memo that states when it will take effect. Senior management can take this opportunity to communicate their support for the policy.

9.9 Summary

In this chapter, I provided a risk management policy for developing a risk ethic within an organization. The activities to develop a policy follow:

1. Obtain commitment.

2. Allocate resources.

3. Survey existing practice.

4. Define draft policy.

5. Review draft policy.

6. Document policy.

7. Approve policy.

8. Communicate policy.

A risk ethic is important to an organization because it establishes the rules of conduct for managing risk. A risk ethic has five such rules:

Take responsibility for risk.

Do not blame people for risk.

Communicate risk to the right people.

Be proactive in managing risk.

Learn from unexpected outcomes.

A risk management policy includes a statement of purpose and responsibility. As a minimum, your policy should contain the following requirements:

1. A risk management plan shall be documented.

2. A baseline risk assessment shall be performed early in the project.

3. Risks shall be reported at weekly status meetings.

4. Risks shall be reviewed at monthly project reviews.

5. A risk database shall be maintained and delivered at project completion.

I described how to establish a firm foundation for managing risk by developing a risk management policy to institutionalize risk management. Because policy directs the way we conduct business, it sets the expectations for organizational behavior. A risk management policy controls behavior by requiring people to manage risk.

9.10 Questions for Discussion

1. Describe how the risk management policy is a strategic plan to institutionalize risk management. Identify the risks of documenting a policy that will be supported by the entire organization. What is your mitigation strategy to combat these risks?

2. Do you agree that anyone can influence policy but policy influences everyone? Discuss why you do or do not agree.

3. Develop a survey that you can give to people that will determine the current risk management practices. Would the survey be different for new business, proposals, projects, and internal research and development teams? Explain your answer.

4. Discuss the concept of commitment. Why is commitment important for long-term success? Give three ways that commitment is demonstrated in an organization from the top down and three ways that commitment is demonstrated from the bottom up.

5. What is a risk ethic? What do you think is the significance of fostering a risk aware culture?

6. What is the point of involving opinion leaders in organizational change? Identify five risks of dictating an organizational policy on software risk management. Discuss the probability and consequence for each of the identified risks.

7. Write a risk management policy for NASA. Write another risk management policy, this time for Microsoft. Compare and contrast the two policies.

8. Write a risk management policy for your organization. Discuss how the terminology reflects your environment.

9. People communicate through vocabulary. Underline and define the important terms used in a risk management policy.

10. You are an engineer working on a large software development. The project schedule is slipping due to technical problems. Management does not appear to know how to change this situation. You have been inspired to make a difference for your project. What will you do? Explain the difference your actions can make for your project.

9.11 References

[Fowler93] Fowler P, Levine L. A conceptual framework for software technology transition. Technical report CMU/SEI-93-TR-31. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1993.

[Fowler92] Fowler P, Levine L. Toward a Designed Process of Software Technology Transition.American Programmer, Vol. 5, Issue 3, page 6, 1992.

[NASA95] National Aeronautics and Space Administration. NASA Systems Engineering Handbook. SP–6105. June 1995.

[Souder87] Souder W. Managing New Product Innovations. Lexington, MA: Lexington Books, 1987.

[VanScoy92] VanScoy R. Software development risk: Problem or opportunity. Technical report CMU/SEI-92-TR-30. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1992.