OFAD 121 MIDLEC

What is a Work Breakdown Structure?

Breaking work into smaller tasks is a common productivity technique used to
make the work more manageable and approachable. For projects, the Work
Breakdown Structure (WBS) is the tool that utilizes this technique and is one of the
most important project management documents. It singlehandedly integrates scope,
cost and schedule baselines ensuring that project plans are in alignment.

The Project Management Institute (PMI) Project Management Book of

Knowledge (PMBOK) defines the Work Breakdown Structure as a “deliverable
oriented hierarchical decomposition of the work to be executed by the project team.”
There are two types of WBS: 1) Deliverable-Based and 2) Phase-Based. The most
common and preferred approach is the Deliverable-Based approach. The main
difference between the two approaches are the Elements identified in the first Level
of the WBS.

Deliverable-Based Work Breakdown Structure

A Deliverable-Based Work Breakdown Structure clearly demonstrates the
relationship between the project deliverables (i.e., products, services or results) and
the scope (i.e., work to be executed). Figure 1 is an example of a Deliverable-Based
WBS for building a house. Figure 2 is an example of a Phase-Based WBS for the
same project.
 FIGURE 1 – DELIVERABLE BASED WORK BREAKDOWN STRUCTURE

In Figure 1, the Level 1 Elements are summary deliverable descriptions. The Level 2
Elements in each Leg of the WBS are all the unique deliverables required to create
the respective Level 1 deliverable.

Phase-Based Work Breakdown Structure

In Figure 2, a Phase-Based WBS, the Level 1 has five Elements. Each of these
Elements are typical phases of a project. The Level 2 Elements are the unique
deliverables in each phase. Regardless of the type of WBS, the lower Level Elements
are all deliverables. Notice that Elements in different Legs have the same name. A
Phase-Based WBS requires work associated with multiple elements be divided into
the work unique to each Level 1 Element.

FIGURE 2 - PHASE BASED WORK BREAKDOWN STRUCTURE

A good WBS is simply one that makes the project more manageable. Every project is
different; every project manager is different and every WBS is different. So, the right
WBS is the one that best answers the question, “What structure makes the project
more manageable?”.

A good Work Breakdown Structure is created using an iterative process by following

these steps and meeting these guidelines:

1. GATHER CRITICAL DOCUMENTS

a. Gather critical project documents.
b. Identify content containing project deliverables, such as the Project
Charter, Scope Statement and Project Management Plan (PMP)
subsidiary plans.
2. IDENTIFY KEY TEAM MEMBERS
a. Identify the appropriate project team members.
b. Analyze the documents and identify the deliverables.
3. DEFINE LEVEL 1 ELEMENTS
a. Define the Level 1 Elements. Level 1 Elements are summary deliverable
descriptions that must capture 100% of the project scope.
b. Verify 100% of scope is captured. This requirement is commonly referred
to as the 100% Rule.
4. DECOMPOSE (BREAKDOWN) ELEMENTS
a. Begin the process of breaking the Level 1 deliverables into unique lower
Level deliverables. This “breaking down” technique is called
Decomposition.
b. Continue breaking down the work until the work covered in each Element
is managed by a single individual or organization. Ensure that all
Elements are mutually exclusive.
c. Ask the question, would any additional decomposition make the project
more manageable? If the answer is “no”, the WBS is done.
5. CREATE WBS DICTIONARY
a. Define the content of the WBS Dictionary. The WBS Dictionary is a
narrative description of the work covered in each Element in the WBS.
The lowest Level Elements in the WBS are called Work Packages.
 b. Create the WBS Dictionary descriptions at the Work Package Level with
detail enough to ensure that 100% of the project scope is covered. The
descriptions should include information such as, boundaries,
milestones, risks, owner, costs, etc.
6. CREATE GANTT CHART SCHEDULE
a. Decompose the Work Packages to activities as appropriate.
b. Export or enter the Work Breakdown Structure into a Gantt chart for
further scheduling and project tracking.

Caution: It is possible to break the work down too much. How much is too much?
Since cost and schedule data collection, analysis and reporting are connected to the
WBS, a very detailed WBS could require a significant amount of unnecessary effort to
manage.

Influencing time, resources and cost estimates quality

A typical statement in the field is the desire to “have a 95 percent probability of meeting
time and cost estimates.”

Past experience is a good starting point for developing time and cost estimates. But
past experience estimates must almost always be refined by other considerations to
reach the 95 percent probability level.

Factors affecting estimates

Factors related to the uniqueness of the project will have a strong influence on the
accuracy of estimates. Project, people, and external factors all need to be considered
to improve quality of estimates for project times and costs.

Planning Horizon

The quality of the estimate depends on the planning horizon; estimates of current
events are close to 100 percent accurate but are reduced for more distant events. The
accuracy of time and cost estimates should improve as you move from the conceptual
phase to the point where individual work packages are defined.
Project Duration

Time to implement new technology has a habit of expanding in an increasing,

nonlinear fashion. Sometimes poorly written scope specifications for new technology
result in errors in estimating times and costs. Long-duration projects increase the
uncertainty in estimates.

People

The people factor can also introduce errors in estimating times and cost. For example,
accuracy of estimates depends on the skills of the people making the estimates. A
close match of people skills to the task will influence productivity and learning time.
Similarly, whether members of the project team have worked together before on
similar projects will influence the time it takes to coalesce into an effective team.

Sometimes factors such as staff turnover can influence estimates. It should be noted
that adding new people to a project increases time spent communicating. Typically,
people have only five to six productive hours available for each working day; the other
hours are taken up with indirect work, such as meetings, paperwork, answering e-mail.

Project Structure and Organization

Which project structure is chosen to manage the project will influence time and cost
estimates. One of the major advantages of a dedicated project team discussed earlier
is the speed gained from concentrated focus and localized project decision

This speed comes at an additional cost of tying up personnel full-time. Converse

projects operating in a matrix environment may reduce costs by more efficiently
sharing personnel across projects but may take longer to complete since attention is
divided and coordination demands are higher.

Padding Estimates

In some cases people are inclined to pad estimates.

For example, if you are asked how long it takes you to drive to the airport, you might
give an average time of 30 minutes, assuming a 50/50 chance of getting there in 30
minutes. If you are asked the fastest you could possibly get there, you might reduce
the driving time to 20 minutes. Finally, if you are asked how long the drive would take
if you absolutely had to be there to meet with the president, it is likely you would
increase the estimate to say 50 minutes to ensure not being late.

In work situations where you are asked for time and cost estimates, most of us are
inclined to add a little padding to increase the probability and reduce the risk of being
late.

If everyone at all levels of the project adds a little padding to reduce risk, the project
duration and cost are seriously overstated. This phenomenon causes some managers
or owners to call for a 10—15 percent cut in time and/or cost for the project. Of course
the next time the game is played, the person estimating cost and/or time will pad the
estimate to 20 percent or more. Clearly such games defeat chances for realistic
estimates, which is what is needed to be competitive.

Organization Culture

Organization culture can significantly influence project estimates. In some

organizations padding estimates is tolerated and even privately encouraged. Other
organizations place a premium on accuracy and strongly discourage estimating
gamesmanship. Organizations vary in the importance they attach to estimates.

The prevailing belief in some organizations is that detailed estimating takes too much
time and is not worth the effort or that it’s impossible to predict the future.

Other organizations subscribe to the belief that accurate estimates are the bedrock of
effective project management. Organization culture shapes every dimension of project
management; estimating is not immune to this influence.

Other Factors

Finally, non-project factors can impact time and cost estimates. For example,
equipment down-time can alter time estimates. National holidays, vacations, and legal
limits can influence project estimates. Project priority can influence resource
assignment and impact time and cost.
Project estimating is a complex process. The quality of time and cost estimates can
be improved when these variables are considered in making the estimates.

Estimates of time and cost together allow the manager to develop a time-phased
budget, which is imperative for project control.

Creating Guidelines for Times, Costs, and Resources

Managers recognize time, cost, and resource estimates must be accurate if project
planning, scheduling, and controlling are to be effective. However, there is substantial
evidence suggesting poor estimates are a major contributor to projects that have
failed.

Therefore, every effort should be made to see that initial estimates are as accurate as
possible since the choice of no estimates leaves a great deal to luck and is not
palatable to serious project managers. Even though a project has never been done
before, a manager can follow seven guidelines to develop useful work package
estimates.

Responsibility

At the work package level, estimates should be made by the person(s) most familiar
with the task. Draw on their expertise! Except for super-technical tasks, those
responsible for getting the job done on schedule and within budget are usually first-
line supervisors or technicians who are experienced and familiar with the type of work
involved. These people will not have some preconceived, imposed duration for a
deliverable in mind.

They will give an estimate based on experience and best judgment. A secondary
benefit of using those responsible is the hope they will “buy in” to seeing that the
estimate materializes when they implement the work package. If those involved are
not consulted, it will be difficult to hold them responsible for failure to achieve the
estimated time.
Finally, drawing on the expertise of team members who will be responsible helps to
build communication channels early.

Use several people to estimate

It is well-known that a cost or time estimate usually has a better chance of being
reasonable and realistic when several people with relevant experience and/or
knowledge of the task are used. True, people bring different biases based on their
experience. But discussion of the individual differences in their estimate leads to
consensus and tends to eliminate extreme estimate errors. This approach is similar to
the Delphi estimating method, which can also be used.

Normal conditions

When task time, cost, and resource estimates are determined, they are based on
certain assumptions. Estimates should be based on normal conditions, efficient
methods, and a normal level of resources. Normal conditions are sometimes difficult
to discern, but it is necessary to have a consensus in the organization as to what
normal conditions mean in this project. If the normal workday is eight hours, the time
estimate should be based on an eight-hour day.

Similarly, if the normal workday is two shifts, the time estimate should be based on a
two-shift workday. Any time estimate should reflect efficient methods for the resources
normally available. The time estimate should represent the normal level of resources
(people or equipment).

For example, if three programmers are available for coding or two road graders are
available for road construction, time and cost estimates should be based on these
normal levels of resources unless it is anticipated the project will change what is
currently viewed as “normal.” In addition, possible conflicts in demand for resources
on parallel or concurrent activities should not be considered at this stage. The need
for adding resources will be examined when resource scheduling is discussed in a
later chapter.
Time units

Specific time units to use should be selected early in the development phase of the
project network. All task time estimates need consistent tiny units. Estimates of time
must consider whether normal time is represented by calendar days, workdays, work
weeks, person days, single shift, hours, minutes, etc. In practice the use of workdays
is the dominant choice for expressing task duration.

However, in projects such as a heart transplant operation, minutes probably would be

more appropriate as a time unit. One such project that used minutes as the time unit
was the movement of patients from an old hospital to an elegant new one across town.
Since there were several life-endangering moves, minutes were used to ensure patient
safety so proper emergency life-support systems would be available if needed.

The point is, network analysis requires a standard unit of time. When computer
programs allow more than one option, some notation should be made of any variance
from the standard unit of time. If the standard unit of time is a five-day workweek and
the estimated activity duration is in calendar days, it must be converted to the normal
workweek.

Independence

Estimators should treat each task as independent of other tasks that might be
integrated by the WBS (Work Breakdown Structure). Use of first-line managers usually
results in considering tasks independently; this is good. Top managers are prone to
aggregate many tasks into one time estimate and then deductively make the individual
task time estimates add to the total.

If tasks are in a chain and performed by the same group or department, it is best not
to ask for all the time estimates in the sequence, at once. This is to avoid the need for
a planner or a supervisor to look at the whole path and try to adjust individual task
times in the sequence to meet an arbitrary imposed schedule or some rough
“guesstimate” of the total time for the whole path or segment of the project.
This tendency does not reflect the uncertainties of individual activities and generally
results in optimistic task time estimates. In summary, each task time estimate should
be considered independently of other activities.

Contingencies

Work package estimates should not include allowances for contingencies. The
estimate should assume normal or average conditions even though every work
package will not materialize as planned. For this reason top management needs to
create an extra fund for contingencies that can be used to cover unforeseen events.

Adding risk assessment to the estimate helps to avoid surprises to

stakeholders.

It is obvious some tasks carry more time and cost risks than others. For example, a
new technology usually carries more time and cost risks than a proven process. Simply
identifying the degree of risk lets stakeholders consider alternative methods and alter
process decisions. A simple breakdown by optimistic, most likely, and pessimistic for
task time could provide valuable information regarding time and cost.

Where applicable, these guidelines will greatly help to avoid many of the pitfalls found
so often in practice.

Estimating Projects

Estimating – The process of forecasting or approximating the time and cost of

completing project deliverables. – The task of balancing expectations of stakeholders
and need for control while the project is implemented.

• Types of Estimates –

Top-down (macro) estimates: analogy, group consensus, or mathematical

relationships –

Bottom-up (micro) estimates: estimates of elements of the wbs

Top-Down versus Bottom-Up Estimating

• Top-Down Estimates

– Are usually derived from someone who uses

experience and/or information to determine the

project duration and total cost.

– Are made by top managers who have little knowledge

of the processes used to complete the project.

• Bottom-Up Approach

– Can serve as a check on cost elements in the WBS

by rolling up the work packages and associated cost

accounts to major deliverables at the work package level.

Types of Costs

• Direct Costs

– Costs that are clearly chargeable

to a specific work package.

• Labor, materials, equipment, and other

• Direct (Project) Overhead Costs

– Costs incurred that are directly tied to an identifiable

project deliverable or work package.

• Salary, rents, supplies, specialized machinery

• General and Administrative Overhead Costs

– Organization costs indirectly linked to a specific

package that are apportioned to the project

Project Networks

A project network (or project activity network) is a graphical depiction (very

similar to a flow chart) that shows the sequence in which the project's terminal
elements must be completed. Each terminal element represents an activity that
relates to a work package at the lowest level of the work breakdown structure (WBS).
However, whereas the WBS does not attempt to identify the sequence of events or
the duration of any activity, the project network seeks to identify the sequence in which
activities occur and the other activities (if any) on which a particular activity depends.
There are a number of techniques used to create a project activity network. Some of
the more commonly used techniques include Gantt charts, Critical Path
Management (CPM) and the Project Evaluation and Review Technique (PERT). In
some techniques, each terminal element (or activity) is represented by a node on a
graph, while in others it is represented by an edge (the line connecting two nodes).
Each terminal element should lie on only one path through the network. An example
of a project activity network diagram is illustrated below.

A generic project activity network diagram

An activity network diagram helps you to determine the most logical sequence of
events for a project, and provides the basis of a realistic project schedule. It will enable
you to calculate the total amount of time required for the project, define the order in
which tasks must be carried out, and highlight those tasks that are critical to the project
schedule. When the WBS has been completed you will have a list of activities at
various levels of decomposition that must be completed in order to achieve the
project’s objectives. You can now determine the task dependencies and the duration
of each task to allow a schedule to be produced. Project management software is now
available that will carry out the scheduling for you, calculate the overall time required
for completing the project, and identify the schedule's critical path. All you have to do
is to enter the duration of each task and identify any task dependencies. The software
will produce network activity charts and Gantt charts based on the information that you
provide.

Although project management software is readily available these days it is useful to

understand the process by which an activity network diagram is created. The following
steps can be used to carry out the process manually:

1. Make a list of all of the tasks that must be completed (these are the work
packages identified as a result of creating the work breakdown structure)
and write the name of each task on a small piece of card or paper (let’s
assume we will use Post-it notes, which are ideal for this purpose).

2. Decide which task must be carried out first (call it Task 1), and place it on
the left-hand side of a large work surface (for the purposes of this exercise
I will assume we will use a whiteboard).

3. Find any other tasks that can be carried out at the same time, and place
them above or below Task 1 on the whiteboard. Identify these tasks (if any)
as Task 2, Task 3 . . . and so on.

4. Decide what the next task will be (Task n), and place it to the right of Task
1. Again, find any other tasks that can be carried out at the same time, and
place them above or below Task n. Continue to number each task as you
place it on the whiteboard.
 5. Repeat the process until all of the tasks are arranged in sequence, and in
parallel, and make sure that each task has been assigned a number.

6. Draw an arrow from each task to the one that immediately follows it.

7. Estimate the time required for each task and write it on the Post-it (use the
same unit of time for each task, i.e. hours, days, or weeks).

8. Find the critical path. This is the path of connected activities which, if the
duration of all of the tasks on it is added together, requires the longest time
to complete.

The critical path tells you how long it will take to complete the entire project (based on
current information). The tasks on the critical path, therefore, must be monitored more
closely than those tasks not on the critical path, because any delays in one of these
tasks will cause the critical path to increase in length (in other words, the time required
to complete the project will increase). One way of reducing the overall duration of the
project, of course, is to speed up the execution of one or more tasks on the critical
path – assuming this is possible. For other paths through the network, each task will
have some slack in the sense that it may be delayed – up to a point – because it is not
on the critical path. Bear in mind however that should one or more tasks on other paths
become significantly delayed, the path affected may acquire an overall duration that
exceeds that of the critical path. It will therefore by definition become the new critical
path.

Gantt charts, PERT and CPM are all useful techniques that provide information about
project schedules in a graphical way, but they do not tell you everything. They do not
tell you, for example, what resources are required for a particular task. Activity network
diagrams are snapshots of the status of a project at a particular time. It will be
necessary to update them as circumstances change. If a task is taking longer than
expected, it may have an impact on the overall project schedule. The same is true for
tasks that are completed ahead of schedule. The impact on resources will not be
apparent from looking at the network diagram alone, and other tools and techniques
must be used to determine where the peaks and troughs will arise in terms of the
demand for critical project resources.
 Level of Detail

There are always questions about the level of detail and frequency of reporting in
project status reports. Our feeling is that the more you report, the more likely it is that
someone will object or find some reason to micro-manage your project. You can
examine this issue in more detail by considering the reporting requirements at the
activity manager, project manager, and senior manager levels.

Activity Manager

The activity manager will want the most detailed and granular information available.
After all, the activity manager is directly responsible for getting the work done. Because
he or she manages the resources that are used to complete project work, he or she
will want to know what happened, what was scheduled to happen, who did what (or
didn’t do what), why it happened as it did, what problems have arisen, what solutions
are within reach, and what changes need to be made. Reports that reflect very detailed
information are of use to the activity manager and the project manager but, because
of their very detail, are of little value to anyone outside of the project team.

Project Manager

The project manager is concerned with the status information of all activities open for
work during the report period. Just as is the case with activity-level reports, there are
reports for the project manager and reports from the project manager to senior
management.

Reports for the project manager present data at the activity level and show effects on
the project schedule. ...

Senior Manager

 A very brief description of the project and its final deadline.

 Current status (schedule and budget)
 Explanations where needed, especially of time and money variances.
 Expectations for the near future - completion of the project compared to deadline.
Risk Management Process

The risk management process is a framework for the actions that need to be taken.
There are five basic steps that are taken to manage risk; these steps are referred to
as the risk management process. It begins with identifying risks, goes on to analyze
risks, then the risk is prioritized, a solution is implemented, and finally, the risk is
monitored. In manual systems, each step involves a lot of documentation and
administration.

Now let’s look at how these steps are carried out in a more digital environment.

Step 1: Identify the Risk

The first step is to identify the risks that the business is exposed to in its operating
environment. There are many different types of risks – legal risks, environmental risks,
market risks, regulatory risks, and much more. It is important to identify as many of
these risk factors as possible. In a manual environment, these risks are noted down
manually. If the organization has a risk management solution employed all this
information is inserted directly into the system. The advantage of this approach is that
these risks are now visible to every stakeholder in the organization with access to the
system. Instead of this vital information being locked away in a report which has to be
requested via email, anyone who wants to see which risks have been identified can
access the information in the risk management system.
Step 2: Analyze the Risk

Once a risk has been identified it needs to be analyzed. The scope of the risk must be
determined. It is also important to understand the link between the risk and different
factors within the organization. To determine the severity and seriousness of the risk
it is necessary to see how many business functions the risk affects. There are risks
that can bring the whole business to a standstill if actualized, while there are risks that
will only be minor inconveniences in the analysis. In a manual risk management
environment, this analysis must be done manually. When a risk management solution
is implemented one of the most important basic steps is to map risks to different
documents, policies, procedures, and business processes. This means that the
system will already have a mapped risk framework that will evaluate risks and let you
know the far-reaching effects of each risk.

Step 3: Evaluate or Rank the Risk

Risks need to be ranked and prioritized. Most risk management solutions have
different categories of risks, depending on the severity of the risk. A risk that may
cause some inconvenience is rated lowly, risks that can result in catastrophic loss are
rated the highest. It is important to rank risks because it allows the organization to gain
a holistic view of the risk exposure of the whole organization. The business may be
vulnerable to several low-level risks, but it may not require upper management
intervention. On the other hand, just one of the highest-rated risks is enough to require
immediate intervention.

Step 4: Treat the Risk

Every risk needs to be eliminated or contained as much as possible. This is done by

connecting with the experts of the field to which the risk belongs. In a manual
environment, this entails contacting each and every stakeholder and then setting up
meetings so everyone can talk and discuss the issues. The problem is that the
discussion is broken into many different email threads, across different documents and
spreadsheets, and many different phone calls. In a risk management solution, all the
relevant stakeholders can be sent notifications from within the system. The discussion
regarding the risk and its possible solution can take place from within the system.
Upper management can also keep a close eye on the solutions being suggested and
the progress being made within the system. Instead of everyone contacting each other
to get updates, everyone can get updates directly from within the risk management
solution.

Step 5: Monitor and Review the Risk

Not all risks can be eliminated – some risks are always present. Market risks and
environmental risks are just two examples of risks that always need to be monitored.
Under manual systems monitoring happens through diligent employees. These
professionals must make sure that they keep a close watch on all risk factors. Under
a digital environment, the risk management system monitors the entire risk framework
of the organization. If any factor or risk changes, it is immediately visible to everyone.
Computers are also much better at continuously monitoring risks than people.
Monitoring risks also allows your business to ensure continuity.

Contingency Planning
Developing a Good "Plan B"

Take precautions to keep your business safe.

Fires, floods, tornadoes – these are the type of events that we often associate with
contingency planning.

But what if your main supplier suddenly goes bankrupt, your entire sales force comes
down with food poisoning, or your website is held to ransom by hackers?

Contingency planning isn't just about major crises and natural disasters. It can also
prepare you for more commonplace problems, such as the loss of data, staff,
customers, or business relationships. That's why it's important to make contingency
planning a routine part of the way you work.

Contingency plans are an essential part of risk management. They help to ensure that
you've always got a backup option when things go wrong, or when the unexpected
happens.

To develop a contingency plan, first conduct a risk assessment: identify your business-
critical operations, identify the threats to those operations, and analyze the potential
impact of each threat.

Then, include the following points for each threat:

 Scenarios.

 Triggers.

 Response overview.

 People to inform.

 Key responsibilities.
 Timeline.

To create the most robust plan, consult widely within your organization, conduct trial
runs, update the plan regularly, and store it securely.

5 Strategies for Managing Opportunities

There are 5 strategies for responding to opportunity risk and they are:

1. Escalate
2. Exploit
3. Enhance
4. Share
5. Accept

1.Escalate

Escalation is also a tactic to use for threat risk and the same approach applies here.
When the opportunity is bigger than the project and falls outside of the scope of your
work, escalate it up to the programme manager or portfolio manager, or simply pass
it on to your boss. There’s nothing you can personally do about it as the opportunity
falls outside of your level of authority. Your job is to make sure that the information you
have is passed on to someone who can best act on it.

You can continue to support whomever picks up the information but you don’t have to
track and manage the risk any longer.

2.Exploit

This strategy is where you basically force the risk to happen so you benefit from
whatever good things are coming your way. You want to increase the probability of
occurrence to 100% because it’s worth it.

That might include spending money or changing the direction of the project to make
sure that you get the outcome you want. For example, you could pull resources from
other projects on to your project to make the work take less time, you could upgrade
some infrastructure to take advantage of technological advances by being able to use
new solutions and so on.

I don’t really use this strategy much because I tend to think that if we take steps to
make something happen, it’s not a risk any more, but that’s just how I think – I know
the literature talks about this as a particular, specific strategy. For me, I wouldn’t ever
have it on the risk register, it would be something we discuss as a team and then adapt
our plans via a change request to make it happen. What would you do? Let me know
in the comments below.

3.Enhance

The Enhance strategy is similar to Exploit in that you want to make the opportunity
happen, but here all you are doing is influencing the outcome – you aren’t forcing the
probability to turn to 100%.

What you try to do is increase the likelihood of it happening or increase the impact it
would have if it did happen. You don’t have a guarantee of the outcome but you are
influencing and negotiating your way to being able to capitalize on that fab opportunity.

I think this is hard to articulate because your response plan relies so much on what
the opportunity is. We identify opportunities throughout the project life cycle and don’t
always record them as risks. For example, if something came up in a team meeting
where we could potentially complete a task more quickly if we had an extra pair of
hands, we would decide there and then to do it and hope for the return, without
necessarily formally documenting the risk.

Perhaps that tells you more about my lackadaisical approach to opportunity

management than it does about the Enhance strategy!

4.Share

Sharing is a little bit like transference for threat risk. It’s where you split the benefit with
a third party on the proviso that they help you try to get the opportunity. For example,
you might share resources for a better outcome, you might set up a joint venture or
create a specific team. All of those things might mean sharing the risk and therefore
the benefit between several entities or teams, but overall may make the potential
benefit larger.

5.Accept

Finally, the classic strategy of do nothing. This is also a valid response and useful
when there isn’t much to be had by way of opportunity. You basically sit it out and wait
to see if the benefit occurs and you might want to have a contingency approach in
place in case it happens and you want to act then.

However, as with accepting threat risk, make sure that you are constantly monitoring
the situation and actively discussing these risks with their risk owners and the team.
You don’t want to be in a situation where you miss an opportunity because the context
or environment changed and your risk response plans weren’t updated as a result.