In Project Management... Risks turn into Issues, and Issues turn into Changes. It is always cheaper to manage risk than the time to manage issues and the money to manage changes. Risk, Issue, and Change Control Management are always part of an effective PMO.

I usually managed the following types of risks:
Executive Risk, Project Management Risk, Functional Risk, Resource Risk, Organizational Risk, and Technical Risk. These have a specific taxonomy.

In the project plan / Bus. Case I have the Risk Type (as mentioned above), the specific risk (e.g. Organizational - change management), the probability of it happening (high, medium, low), the severity of the risk if it happened (high, medium, low), and the actions (risk is managed, eliminated, transferred or mitigated.) and the action details.

In your case, the "budget risk" is a specific resource risk that if it happend you could chose to transfer to a client, for example, billing an overun.

The culture is built by explaining how an energy shift from "dealing with issues" vs. "identifying and managing risk" is less time consuming in the end.

Links:

• http://www.ideasareorange.com

Andres N also suggests this expert on this topic:

• Jorge C

posted March 23, 2007

Risks are what may/could happen - you can quantify them - but I would suggest doing this only where the probability is high(red), the risk is material to the project and its time to reforecast. Risks should be mitigated - this is the most important aspect of risk management, regular reviews of risks is all important, rather then HML assign a RAG status - this allows you at a glance to manage better. Make sure also that the risks are reviewed on a regular basis and that they are assigned an owner. A risk log is a very effective management tool, but only if monitored and managed.

Hope this help

posted March 23, 2007

Rob, I am suggesting Mr. Fekete who is an expert in this field. He has just joined LinkedIn therefore you will not see a lot in his profile, yet. I have an ongoing project cooperation with him with similar focus.
rgds,
Peter

posted March 23, 2007

Interesting question.
Methods I have used include:
Duncan's Uncertainty Theory
Monte Carlo Technique
plus other methods.

Duncan's theory is an interesting application of risk assessment, it combines two axes, Complexity against Volatility. It proved an incredibly useful method of assessing the risks associated with software/hardware deployments. Best of all it can be communicated and understood by all levels of an organisation.

The Monte Carlo method was also very useful when assessing risk. In this method a degree of past information is required to seed the model but after the initial seeding the model is a live risk assessment tool.
Essentially if we take a project and the associated tasks, by WBS, we schedule the project as normal with time and resource allocation. We then use the time allocations to determine an average time for the execution of each WBS element. The Monte Carlo model, Excel will do, is used to give a probabalistic determination of how long each WBS may take to build.
Sequencing these to follow the project plan then allows the project to be built 100's of times within the model.
As we execute the real project we update the seeded values with actuals and see the impact on the model. Downside is the investment in time unless you are planning to execute repetitious projects i.e. deploy 3 x HA Clusters, if you do this at 5 customers then the investment in time is offset by the accuracy of the project plan and the associated risks.

posted March 23, 2007

There is a variety of risk parameters not only financial. To get project risk management on a professional footing you would have to take at least the following (not complete) asprects into account. Funding and where the funding would come from in an overrun situation is merely an internal governance issue. Andres also made a reasonable high level list. The starting point for risk management would be to use the elements within the PMBOK guide book (PMI.org), in a second (more in depth) manner would be to look at quality control and related techniques (as that has a drastic impact on risk mitigation).

Key to risk management is:
1. Risk identification (early as possible)
2. Risk analysis
3. Risk mitigation strategy, ideally risk avoidance
4. Risk management and control

Some of the aspects to take into acount include the following:
1. Financial
2. On time delivery (a late delivery does not always translate to a financial overshoot)
3. Business Risk: (several parameters here)
- Being late - cost to business if software is not in-time - this can vary from virtually zero to backrupt. - a recent case I had a late delivery would have meant the latter.
- Business risk in terms of project implementation (especially when changing mission critical software).
4. Resource risks - do you have the appropriate level of resources within the technically high risk areas for risk mitigation
5. Technical Risks - Do you depend on a technically challenging solution or on something never done before.
6. Supplier risks
7. Implementation risks - including data migration, failover etc.

An old technique embedded in CPM included judging/calculating the risk per activity (suggest - go deeper where the risk is high, and shallow where the risk is low). Similations (e.g. Monte Carlo) provides a good estimate, but an educated judgement based on experience is much better. By rollingup the CPM estimations, you can know the risk of on-time project delivery. Now depending on the risk profile, and acceptable risk variances that the project can accept, you would already have an idea should the project be able to deliver on time, within budget etc, and what the impact is likely to be on those (at least on a statistical level). The great part of that is that it also provides for a measure (or rather a set of measures) whereby project risk and risk mitigation could be measured. Hence it would be possible to know if your risk mitigation strategies are working and the risk reducing during the project delivery. Should you not measure in that manner, then you have what often happens, that the project is going "well" until it hits the "80%" mark, and then suddenly overrun, or have other major problems. The latter is usually an indication that neither the PM nor the Project Risk Manager managed their risks appropriately.

posted March 24, 2007

I worked on a model of risk management for EPC Companies, during the procurement Phase. What I found out, after some researches, is that the perception of High/Med/Low are totally subjective, but are still a good starting point. If you want a better measure, what you can try to measure 'economically' the risk esposition, is to use triangular distribution (nothing more complex) to assess the probability (setting as central value, the value you attribute to 'High'/'Med'/'Low', and boundaries +/- 25% - to be refined- if you want to describe a simmetrical perception).
I think that great misunderstandings in risk perception depend on a wrong perception of risk sources, rather than wrong perception of risks themselves. I think a good idea is to use hierarchical structures (as well as WBSs or OBSs) to model risk sources, and then build a risk cube (WBS-OBS-RiskBS) to measure impacts and impacted activities.

posted March 24, 2007

Hi Rob,

I have used many methods over the years.

Normal process is:

Have a project risk register
Identify risks - through brainstorming/workshop
Analyse the risks
Rate for Impact
Rate for Probability
For all risks at and above Impact = Medium and Probability = Medium identify mitigation plan and contingency plan
Optional - identify scale of impact (cost or time) if risk becomes an issue
Review on a regular basis - review top risks/issues at least weekly

Escalate top 3 or 5 risks and issues (and action plans) to senior management

I hope this helps

Regards

Chris

posted March 24, 2007

Rob,

Project Risk falls under the auspices of Risk Management. Identification of the risks associated
with business activities and decision making
may be categorised as strategic, project/
tactical, operational.

Therefore, it is important to
incorporate risk management at the
conceptual stage of projects as well as
throughout the life of a specific project.

As suggested by other respondents, it would be prudent to compile a Risk Register (Red/Green/Amber) and indeed put in sysyems and controls to reduce the identified risk to a residual risk.

Costing (depending on magnitude of project) may warrant the Monte Carlo Analysis / 3 Point estimating techniques.

Implementing a Project Risk Management culture will firstly require the understanding of Risk Management principles.

www.theirm.org is a good place to start.

Hope this has been useful.

posted March 25, 2007

I manage to understand Risk better when am start to read about Insurance .

Cheers

posted March 26, 2007

Hi Rob.

I have implemented Risk identification, analysis, assessment, scheduling and management in my organization, and as the list above indicates assessment is just one part of the problem. Let me try to give you a short introduction to what we did, and then you can judge for yourself, if it might be usefull to you. It is based on the defacto risk management techniques out there and then customized a bit.

1. Risk identification. Check Leavitts model: http://informationr.net/tdw/publ/papers/leavitt.gif
It talks about the areas, you should find Risks in.
Technology: What you need technically to solve the task.
People: Project members, Project Manager, Internal leadership, Direct Customer, End Customer, Stakeholders.
Task: The project at hand
Structure: Project plan, internal company structure, Projects structure.

Also the model states that these areas affect eachother.

To find Risks I just what you might call negative innovation. We sit down and become paranoid and find all the risks, we can in all the areas, we can. Invite trusted stakeholders or trusted customers. Why? we are guessing about what might happen in the future, and the way to do this, is to do too much, cover all angles, and later narrow the field.

Now we have a list, which we register electronically.

Analysis:
Pretty simple, look at each risk and determine how likely it is to occur, and if we simply don't know, we find out. Ask experts, whatever it takes, use best guesses. Our experience is that we can determine likelyhood of 95% of the risks our selves and weed out about 50% allready.

Assessment: Estimate the impact of the risk. We have a number of units. Monetary, Extra hours, Movement of milestone and delivery dates, Our credibility, Project death. Again, if we simply don't know, Ask experts, whatever it takes. Usually we estimate about 95% ourselves and weed out another 30% of the remainder.

Scheduling:
Back to Leavitts model: If a Risk occurs it is likely to set others off as well. Why? They affect eachother. Simple Example. John knows all about A.
To solve tasks X and Y, you need to know about A. Ergo John must solve these tasks.
There is no time for John to instruct others in A.
Risk R1 comes into affect, and to solve that you need to know about A, so task X is going to be late.
Now John solves risk R1 and goes on maternati leave, and there is noone to solve task X.
So we try to schedule dependant risks away from eachother in different milestones, if possible.
Management:
For each risk, plan an action to counter the risk and carry it out in accordance with the scheduling.
For each risk, if the countering action didn't work, create a mitigation plan, or just plan B.
For each risk, assign measuring points?!?: A measuring point is a concrete value, which if hitting some limit gives an indication that the risk is comming into effect.
Example: You need hardware H from subcontracter C or delivery D is going to be late. And the hardware should work. Measuring points: The specific date, when you should receive the hardware, one week before and two weeks before (more follows).
You now measure your measuring points at assigned dates to check if the risk is comming into effect.
Two weeks before delivery D, we call the subcontractor to hear if they have begun testing the hardware, and if they think we will receive it on time. If they say no, the risk is comming into effect. We call them again, one week before delivery D to ask, how the tests are going and do they still think, they will makeit.
The final measuring point we just see if the hardware is on our doorstep.

Time spent doing all this.
Lets say a 10 manyear project.
At project startup.
1 days risk identification
1 days risk assessment
1 days risk scheduling and management
Continuously:
1 hour a week after that measuring.
At milestones and deliveryies.
Less.

Hope you could use it.

Kind Regards

posted March 27, 2007

Risk is the main reason why projects exist. A dynamic approach to managing the risks affecting the project is an integral part of managing the project. It is the approach to risk management that should determine the value of the risk assessment approaches that feed into it.

I wish I could take it as read that the project will have one or more planned levels of residual risk exposure at the completion of each phase. DO THIS! If these targets are defined in measurable terms, then tracking of composite residual risk should use the same scales of measure. The assessment of the residual component of individual risks is then an extension of the approach to composite residual risk.

For example, the individual risk is viewed as the project's only risk and the project's composite residual risk measurement in that hypothetical case is taken as the individual residual risk measurement. An advantage of this approach is that composite residual risk is then equal, by definition, to the sum of the individual residual risk levels. A disadvantage is that multiplier effects (of one risk on another) are not naturally handled. However, by assessing the multiplier effects as individual risks, this disadvantage can be mitigated.

Another disadvantage is that the assessed risk levels are necessarily estimates, so there is uncertainty in the implicit or explicit range of values that applies to an individual risk, and hence (even more so) to the composite risk values. I find that using percentages helps here: an individual risk currently represents between, say, 4% and 12% of the phase completion target. You can only make interesting observations like this if you have numeric assessments, of course. That could be monetary value, other numbers such as mandays, or just "points".

HML or RAG approaches can easily be adapted by scoring the different levels. This needs to be done by reference to your targets for composite residual risk. If your target is "all risks Green", for example, then a Green risk makes zero contribution to the the project's residual risk, so it should have zero points. Conversely, if your target is "no risks Red", then each Red risk represents at least 100% of your risk quota. It is this type of feedback loop that leads me away from RAG and towards HML or genuine numbers. The RAG status is then some function of the relationship between the individual risk and the target.

posted March 27, 2007