9.4 Conventional project management techniques

Richard E. (Dick)

Источник: Richard E. (Dick) Fairley Managing and leading software projects // a John Wiley & Sons, inc., publication. 2009.

The conventional techniques of project management presented in this text can be thought of as institutionalized risk management. Over time it has become apparent that applying conventional techniques such as:

– planning and estimating,
– managing requirements,
– preparing work breakdown structures,
– establishing schedule networks, and and measuring progress using techniques such as:
– iterative development,
– binary tracking, and
– earned value reporting, improve the chance of success by reducing risk exposure. In other words, it is better to do conventional project management than to not do it.

Risk management augments conventional project management techniques.

Explicit management of assumptions and constraints, for example, is a key element of risk management. As described previously in this text (Chapter 4) assumptions are conditions that you assume will be true but cannot verify during planning. You might assume, for example, that suffi cient numbers of personnel who have the necessary skills will be available when needed. Or, you might assume that product complexity will not be a problem because you expect to have software developers who are familiar with this kind of system. Assumptions are potential problems (risk factors); assumptions proved to be false create real problems.

Constraints are externally imposed conditions that your project must satisfy (i.e., factors that are beyond your control as project manager). They are limitations that have been imposed on project attributes such as:

– the schedule,
– budget,
– available resources,
– software to be reused,
– technologies to be used, and
– interfaces to other systems.

Constraints can be categorized as design constraints and process constraints. A design constraint might require reuse of existing components or building specifi ed interfaces to another system. A process constraint might limit the money, resources, and/or time available to conduct the project. More restrictive constraints create risk factors having higher probabilities of becoming problems that will impede delivering an acceptable product within schedule and budget.

Risk factors created by project constraints can sometimes be avoided by modifying the constraints. Process constraints (schedule, budget, resources) and product constraints (features and quality attributes) should be examined. Some constraints may be essential to a successful outcome. Others, on closer examination, may be relaxed or removed. An operational requirement for “near instantaneous response time ” may be acceptably satisfi ed with a 5 – second response time rather than the stated requirement for a 2 – second response time, for example. The increased response time may signifi cantly decrease the probability that a risk factor will become a problem.

Risk management augments conventional project management in (at least) three ways. First, you can actively manage assumptions and constraints by: – explicitly itemizing them,
– identifying the associated risk factors,
– prioritizing the risk factors,
– tracking risk indicator metrics,
– periodically reviewing the risk factors, and
– pursuing mitigating actions as necessary.

Second, you can:

– set threshold values for the risk indicator metrics and other project parameters (e.g., schedule performance index, cost performance index, requirements volatility) and
– prepare responses (i.e., develop mitigation plans) to be initiated if those thresholds are violated.

You, your customer, and your managers may tolerate a 2 – day delay in achieving a major project milestone but you and they may agree, in advance, that a delay of more than 2 weeks in achieving a major milestone will trigger mitigating actions. Or, you may agree that a memory overrun of more than 10% on any weekly build – demonstration cycle will trigger a mitigating action.

As indicated throughout this text, there are acceptable and unacceptable ways to compensate for problems in a software project. Acceptable methods include: – increasing the schedule,
– increasing the budget,
– applying more resources,
– applying better resources,
– reducing the requirements; and
– improving the work processes.

Unacceptable methods include:

– requiring excessive overtime;
– reducing verifi cation and validation activities; and
– reducing user, customer, support, and maintenance aids and documentation.

The third way in which risk management augments conventional project management is by using a systematic approach to identify, analyze, prioritize, and mitigate specifi c risk factors for your project, during initial planning and on an ongoing basis. You may be using the conventional methods, tools, and techniques presented in this text to plan and estimate, measure and control, and lead and direct your project, but if you are not doing systematic risk management, you may fail to identify and respond to specifi c risk factors with suffi cient lead time to avoid crisis situations. Identifi ed risk factors must be prioritized because some risk factors, and some interactions among risk factors, may have larger probabilities and/or greater potential impact than others and thus should receive more attention and resources. Risk mitigation strategies must be devised. In some cases, risk mitigation involves taking immediate action to reduce the probability and/or potential impact of an identifi ed risk factor. In other cases, risk mitigation involves tracking a risk indicator and taking action if (when) a potential problem becomes a real problem (i.e., when a trigger value crosses a predetermined threshold — the problem trigger). In some cases, decisions about how to deal with identifi ed risk factors may be deferred until the situation is better understood.

In cases where the correct course of risk management is uncertain, 29 and in cases where a mitigating action is not apparent, you should place identifi ed risk factors on a watch list that is reviewed at frequent intervals; risk mitigation actions are then initiated as appropriate. Techniques for prioritizing risk factors and strategies for mitigating project risk are discussed later in this chapter.

Software projects often have risk factors that are unknown during initial planning but become apparent later in a project. It is not uncommon to allocate a contingency reserve to be used when unknown risk factors appear later in a project. The amount of money in the contingency reserve may range from 10% to 50% or more of the project budget, depending on the level of uncertainty during initial planning. Many of the conventional techniques of project management can be used to manage risk factors. Table 9.3 lists some of the techniques that can be used to manage the risk factors listed by Boehm in his top – 10 list of risk factors for software projects [Boehm91] . The following sections present techniques for risk identifi cation, analysis and prioritization of risk factors, and risk mitigation strategies.

Table 9.3 Risk factors and risk management techniques

In cases where the correct course of risk management is uncertain, and in cases where a mitigating action is not apparent, you should place identifi ed risk factors on a watch list that is reviewed at frequent intervals; risk mitigation actions are then initiated as appropriate. Techniques for prioritizing risk factors and strategies for mitigating project risk are discussed later in this chapter.

Software projects often have risk factors that are unknown during initial planning but become apparent later in a project. It is not uncommon to allocate a contingency reserve to be used when unknown risk factors appear later in a project. The amount of money in the contingency reserve may range from 10% to 50% or more of the project budget, depending on the level of uncertainty during initial planning. Many of the conventional techniques of project management can be used to manage risk factors. Table 9.3 lists some of the techniques that can be used to manage the risk factors listed by Boehm in his top – 10 list of risk factors for software projects [Boehm91] . The following sections present techniques for risk identifi cation, analysis and prioritization of risk factors, and risk mitigation strategies.