Managing Risks

By -

Managing Risks

Risks, like a well-known comedian, get no respect. Project managers dutifully assess them at the start of the project, record them in the project plan, then forget about them until one of them lunges up to destroy any pretense that the project was on track.

You need to manage risks; they must be in the forefront of your concerns. Ensure that risks are an agenda item for the weekly team meeting (see ''Team Meetings"), that risks are a heading in the project status report (see "Reporting Status"), and that risks are a topic in your weekly reflection (see "Reflection").

In the team meeting, briefly review with the team all outstanding risks (a risk is outstanding when there is a probability that it will occur) and ask them to estimate whether each risk's probability has increased, has decreased, or is unchanged. Then ask if there are any new risks that anybody can think of. It may not be pleasant when someone says, "Oops, I forgot to mention my holidays." But you would rather hear it now than wonder, at a critical point in the project, where Fred is.

In the project status report, list all risks where the degree of risk has changed.

In your weekly reflection, review all risks, even those that have been eliminated. You want to prompt yourself to uncover new risks or those that have been reincarnated.

The purpose of overtly reviewing risks is, of course, to keep them in your awareness and to sensitize all team members to them. The reason for including them in the project status report is to prepare your management for the day when you will say, "You are aware, of course, of [risk]. Well it has happened."

What If?

You Discover That Team Members Are Not Telling You of Risks That They Consider "Not Significant."

Most team members have a limited view of the project compared to yours, which is more global. Therefore, the fact that someone sees a risk as being insignificant means only that it is insignificant for one part of the project. It may be acute for the project as a whole.

Actions

When you find a risk that you have not been told about, raise it at a team meeting and point out why it is significant to the project.

Make it clear that assessing risks is your responsibility, not that of any other team member. One by-product of this stance is that when anyone suggests a potential risk, you must not dismiss it on the spot; if you do, you will not get any other suggestions.

Be persistent in reviewing existing risks and seeking out new ones.

Some Team Members continually Raise Risks That Are Trivial.

Other than the annoyance factor, there are no consequences to your project. However, the team member's persistence probably indicates a degree of immaturity, combined with an enthusiasm that is worth nurturing.

Actions

Ask the team member to rate the risks according to the probability/ impact model and to give reasons for each rating.

Review the risk assessment and provide feedback on its accuracy and on the kinds of risk that you are looking for.

Comments

Post a Comment

Popular posts from this blog

The Conversion Cycle:The Traditional Manufacturing Environment

By -
Image
The Traditional Manufacturing Environment The conversion cycle consists of both physical and information activities related to manufacturing products for sale. The context-level data flow diagram (DFD) in Figure 7-1 illustrates the central role of the conversion cycle and its interactions with other business cycles. Production is triggered by customer orders from the revenue cycle and/or by sales forecasts from marketing. These inputs are used to set a production target and prepare a production plan, which drives production activities. Purchase requisitions for the raw materials needed to meet production objectives are sent to the purchases procedures (expenditure cycle), which prepares purchase orders for vendors. Labor used in production is transmitted to the payroll system (expenditure cycle) for payroll processing. Manufacturing costs associated with intermediate work-in-process and finished goods (FG) are sent to the general ledger (GL) and financial reporting system. Dependin...
Read more

The Revenue Cycle:Manual Systems

By -
Image
Manual Systems The purpose of this section is to support the system concepts presented in the previous section with models depicting people, organizational units, and physical documents and files. This section should help you envision the segregation of duties and independent verifications, which are essential to effective internal control regardless of the technology in place. In addition, we highlight inefficiencies intrinsic to manual systems, which gave rise to modern systems using improved technologies. SALES ORDER PROCESSING The system flowchart in Figure 4-12 shows the procedures and the documents typical to a manual sales order system. In manual systems, maintaining physical files of source documents is critical to the audit trail. As we walk through the flowchart, notice that in each department, after completion of the assigned task, one or more documents are filed as evidence that the task was completed. Sales Department The sales process begins with a customer cont...
Read more

Nassi-Shneiderman charts

By -
Image
Nassi-Shneiderman charts 56.1 Purpose Nassi-Shneiderman charts were developed by Nassi and Shneiderman as an alternative to traditional logic flowcharts. Their intent was to provide a structured, hierarchical, graphical view of the flow of logic through a program, a routine, a module, or a process. Nassi-Shneiderman charts are used to document, plan, and design detailed program logic. 56.2 Strengths, weaknesses, and limitations A properly prepared Nassi-Shneiderman chart can illustrate the flow of logic through a module or routine at a glance. Nassi-Shneiderman charts are useful for describing or planning relatively small modules, routines, or processes. They can be used to clearly show nesting and recursion, and are easily converted to structured code. Nassi-Shneiderman charts should not be used for documenting complete programs or large routines. As a general rule, Nassi-Shneiderman charts should be limited to a single page with no more than 20 subdivisions. For larger rout...
Read more