Category Archives: Risk

Risk management handbook published

The RM Handbook coverThe Risk Management Handbook edited by Dr. David Hillson (the ‘risk doctor’) is a practical guide to managing the multiple dimensions of risk in modern projects and business.  We contributed Chapter 10: Stakeholder risk management.

The 23 Chapters are a cutting-edge survey of the risk management landscape, providing a broad and up-to-date introduction to risk, with expert guidance on current best practice and cutting-edge insight into new developments within risk management.

For more on the book, see: www.koganpage.com/product/the-risk-management-handbook-9780749478827

The language used to define risks can contribute to failure.

Risk1If a risk is going to be adequately managed, it needs to be defined.  Failing to describe the actual risk (or risks) will almost inevitably lead to project failure and will frequently exacerbate the damage.

In recent times, there seems to be an explosion of documents in the public domain, including academic papers (where one would have hoped the reviewers and editors knew better) listing as ‘risks’ factors that cannot ever be risks.  The ‘fact’ hides the real or consequential risks that may be manageable.

RiskRisk 101 – a risk is an uncertainty that may affect a project objective if it occurs. For something to be a risk, there has to be an uncertainty and the uncertainty may have a positive or negative impact on one or more objectives (see more on risk management). Risk management involves balancing the uncertainty, its potential impact and the cost and effort needed to change these for the better. But to do this you need to focus on the uncertainties that can be managed.

head-in-sandOne of more frequently miss-described risks is ‘technical complexity’.  The degree of technical difficulty involved in a project is a FACT that can be measured and described!  Some projects such as launching a space rocket are technically complex, other less so; but NASA has a far higher success rate in its rocket launches than most IT departments have in developing successful software applications that achieve their objectives.  The technical difficulty may give rise to consequential risks that need addressing but these risks have to be identified and catalogued if they are going to be managed. Some of the risks potentially arising out of technical complexity include:

  • Inadequate supply of skilled resources in the marketplace / organisation;
  • Management failing to allow adequate time for design and testing;
  • Allowing technicians to ‘design in’ unnecessary complexity;
  • Management failing to provide appropriately skilled resources;
  • Management lacking the skills needed to properly estimate and manage the work;
  • Etc.

Another common risk in many of these pseudo risk lists is ‘lack of senior management support’.  This is a greyer area, the project team’s perception of management support and the actual level of support from senior management may differ. Developing an understanding of the actual attitude of key senior managers requires a methodical approach using tools such as the Stakeholder Circle.  However, even after defining the actual attitude of important senior managers the lack of precision in the risk description will often hide the real risks and their potential solutions or consequences:

  • If there is a real lack of senior management support the project should be cancelled, its probability of failure is greater than 80%. Continuing is simply wasting money.
  • If the problem is senior management failing to understand the importance of the project, this is an issue (it exists) and the solution is directed communication (see more on directed communication). The risk is that the directed communication effort will fail, leading to project failure, this risk needs careful monitoring.
  • If the problem is a project sponsor (or steering committee) who is not committed to project success and/or a sponsor (or steering committee) lacking understanding of his/her role (see more on the role of a sponsor) this is another issue with a solution based in education or replacement. Depending on the approach to resolving the issue (and its guaranteed impact on project success if the issue remains unresolved) the risk is either the necessary education process may not work and/or poor governance and senior management oversight will allow the issue to continue unresolved – these specific risks need to be explicitly described and acknowledged if they are to be managed.

Fine tune your detectorsThe first step to managing risks effectively is developing a precise description of the actual risk that requires managing. If there are several associated risks, log each one separately and then group them under a general classification.   The description of each risk is best done using a common meta language such as:

  • ‘[Short name]: If a [description of risk] caused by [cause of risk] occurs, it may cause [consequence of occurrence]’. For example:
  • ‘Storms: If a heavy thunderstorm caused by summer heat occurs, it may cause flooding and consequential clean up’.

For each risk you need to:

  • Define the risk category and short name;
  • Describe the risk using an effective ‘risk meta language’;
  • Determine if the risk is an opportunity or threat and quantify its effect;
  • Prioritise the risk using qualitative assessment process;
  • Determine the optimum response;
  • Implement the response and measure its effectiveness (see more on risk assessment).

A simple Excel template such as this can help: http://www.mosaicprojects.com.au/Practical_Risk_Management.html#Tools

Managing issues is similar, the key difference is the consequences of an unresolved issue are certain – the issue is a fact that has to be dealt with (see more on issues management).

There are a number of factors that can cause both risks and issues to be improperly defined, some technical, most cultural. Three of the most important are:

  • Dealing with easy to identify symptoms without looking for the root cause of the risk / issue (see more on root cause analysis).
  • A management culture that does not allow open and honest reporting of risks and issues; preferring to hide behind amorphous descriptions such as ‘technical complexity’ rather than the real risk ‘management’s inability to manage this level of complicated technology’.
  • Failing to allow adequate time to analyse the stakeholder community using tools such as the as the Stakeholder Circle so that the full extent of risks associated with people’s capabilities and attitudes can be understood – these can account for up to 90% of the actual risks in most projects.

Management culture is the key to both allowing and expecting rigorous and honest assessment of risk. One of the key functions of every organisation’s governing body is to design, create and maintain the organisation’s management culture, this is a problem that starts at the top! For more on the roles of governance see: http://www.mosaicprojects.com.au/WhitePapers/WP1096_Six_Functions_Governance.pdf.

Project Risk Management – how reliable is old data?

One of the key underpinnings of risk management is reliable data to base probabilistic estimates of what may happen in the future.  The importance of understanding the reliability of the data being used is emphasised in PMBOK® Guide 11.3.2.3 Risk Data Quality Assessment and virtually every other risk standard.

One of the tenets underpinning risk management in all of its forms from gambling to insurance is the assumption that reliable data about the past is a good indicator of what will happen in the future – there’s no certainty in this processes but there is degree of probability that future outcomes will be similar to past outcomes if the circumstances are similar. ‘Punters’ know this from their ‘form guides’, insurance companies rely on this to calculate premiums and almost every prediction of some future outcome relies on an analogous interpretation of similar past events. Project estimating and risk management is no different.

Every time or cost estimate is based on an understanding of past events of a similar nature; in fact the element that differentiates an estimate from a guess is having a basis for the estimate! See:
–  Duration Estimating
–  Cost Estimating

The skill in estimating both normal activities and risk events is understanding the available data, and being able to adapt the historical information to the current circumstances. This adaptation requires understanding the differences in the work between the old and the current and the reliability and the stability of the information being used. Range estimates (three point estimates) can be used to frame this information and allow a probabilistic assessment of the event; alternatively a simple ‘allowance’ can be made. For example, in my home state we ‘know’ three weeks a year is lost to inclement weather if the work is exposed to the elements.  Similarly office based projects in the city ‘know’ they can largely ignore the risk of power outages – they are extremely rare occurrences. But how reliable is this ‘knowledge’ gained over decades and based on weather records dating back 180 years?

World-Temprature

Last year was the hottest year on record (by a significant margin) as was 2014 – increasing global temperatures increase the number of extreme weather events of all types and exceptionally hot days place major strains on the electrical distribution grids increasing the likelihood of blackouts.  What we don’t know because there is no reliable data is the consequences.  The risk of people not being able to get to work, blackouts and inclement weather events are different – but we don’t know how different.

Dealing with this uncertainty requires a different approach to risk management and a careful assessment of your stakeholders. Ideally some additional contingencies will be added to projects and additional mitigation action taken such as backing up during the day as well as at night – electrical storms tend to be a late afternoon / evening event. But these cost time and money…..

Getting stakeholder by-in is more difficult:

  • A small but significant number of people (including some in senior roles) flatly refuse to accept there is a problem. Despite the science they believe based on ‘personal observations’ the climate is not changing…….
  • A much larger number will not sanction any action that costs money without a cast iron assessment based on valid data. But there is no valid data, the consequences can be predicted based on modelling but there are no ‘facts’ based on historical events……..
  • Most of the rest will agree some action is needed but require an expert assessment of the likely effect and the value proposition for creating contingencies and implementing mitigation activities.

If it ain’t broke, don’t fix it???? 

The challenge facing everyone in management is deciding what to do:

  • Do nothing and respond heroically if needed?
  • Think through the risks and potential responses to be prepared (but wait to see what actually occurs)??
  • Take proactive action and incur the costs, but never being sure if they are needed???

There is no ‘right answer’ to this conundrum, we certainly cannot provide a recommendation because we ‘don’t know’ either.  But at least we know we don’t know!

head-in-sandI would suggest discussing what you don’t know about the consequences of climate change on your organisation is a serious conversation that needs to be started within your team and your wider stakeholder community.

Doing nothing may feel like a good options – wait and see (ie, procrastination) can be very attractive to a whole range of innate biases. But can you afford to do nothing?  Hoping for the best is not a viable strategy, even if inertia in your stakeholder community is intense. This challenge is a real opportunity to display leadershipcommunication and  negotiation skills to facilitate a useful conversation.

Extreme Risk Taking is Genetic……

A recent 2014 scientific study, Going to Extremes – The Darwin Awards: sex differences in idiotic behaviour highlights the need for gender diversity.  The class of risk studied in this report is the idiotic risk, one that is defined as senseless risks, where the apparent payoff is negligible or non-existent, and the outcome is often extremely negative and often final. The results suggest that having an ‘all male’ or male dominated decision making group may be a source of risk in itself.

Darwin1Sex differences in risk seeking behaviour, emergency hospital admissions, and mortality are well documented and confirm that males are more at risk than females. Whilst some of these differences may be attributable to cultural and socioeconomic factors (eg, males may be more likely to engage in contact and high risk sports, and are more likely to be employed in higher risk occupations), sex differences in risk seeking behaviour have been reported from an early age, raising questions about the extent to which these behaviours can be attributed purely to social and cultural differences. This study extends on these studies to look at ‘male idiot theory’ (MIT) based on the archives of the ‘Darwin Awards’. Its hypothesis derived from Women are from Venus, men are idiots (Andrews McMeel, 2011) is that many of the differences in risk seeking behaviour may be explained by the observation that men are idiots and idiots do stupid things…… but little is known about sex differences in idiotic risk taking behaviour.

Darwin2The Darwin Awards are named in honour of Charles Darwin, and commemorate those who have improved the human gene pool by removing themselves from it in an idiotic way (note the photographs are both of unsuccessful attempts to win an award).  Whilst usually awarded posthumously, (the idiot normally has to kill themselves) the 2014 The Thing Ring award shows there are other options.  Based on this invaluable record of idiotic human behaviour, the study considered the gender of the award recipients over a 20 year period (1995-2014) and found a marked sex difference in Darwin Award winners: males are significantly more likely to receive the award than females.

Darwin3Of the 413 Darwin Award nominations in the study period, 332 were independently verified and confirmed by the Darwin Awards Committee. Of these, 14 were shared by male and female nominees (usually overly adventurous couples in compromising positions – see: La Petite Mort) leaving 318 valid cases for statistical testing. Of these 318 cases, 282 Darwin Awards were awarded to males and just 36 awards given to females. Meaning 88.7% of the idiots accepted as Darwin Award winners were male!

Gender diversity on decision making bodies may help to reduce this potential risk factor in two ways.  First, by reducing the percentage of people potentially susceptible to MIT. Second, by modifying the social and cultural environment within decision making body, reducing the body’s tendency to take ‘extreme risk decisions’.

One well documented example is the current Federal Government. Given the extremely limited representation of women in the make-up of the current Abbott government, and some of the self-destructive decisions they have made, I’m wondering if there is a correlation. A softer, less aggressive, lower risk approach to implementing many of the policies they have failed to enact may have resulted in a very different outcome for the government.

Dealing with client delay

DelayPreventing or minimising client induced delay is a common issue from small ‘agile’ IT developments through to multi-$billion mega projects.  Whilst this type of delay can never be completely eliminated, they can be reduced by applying a pragmatic six stage approach.

 

Stage 1:  Make sure your needs are known and understood by the client.

The best way to minimise delays is to ensure the client understands not only ‘what’ they are expected to contribute but also ‘why’ it is needed – don’t make the mistake of believing ‘they understand’, just because it is their project. Proactive communications is the key to helping your client better understand their role and the consequences of a delay on their part. Some of the questions you need to answer are:

  • Does the client understand the importance of their involvement?
  • Does the client really understand the need for timely feedback?
  • Do they appreciate the impact to the project if they are late / slow?
  • Do they know the dates that they will need to undertake actions so they can plan their work?

You will be surprised how valuable communicating proactively and raising visibility of the potential problems can be; the key is making sure the client develops an understanding of the requirements and the amount of effort needed for them to meet their obligations. This is a form of ‘directed communication’; see: The three types of stakeholder communication.

Stage 2:  Schedule the activity and code it up to make extracting focused reports easy.

A vital tool on the communication lexicon is clearly presented schedule information that is relevant to the client. Make sure their work is defied by activities that can be easily pulled into a focused report. Do not use lags on links to allow time for this work – no one is responsible for the ‘lag’.

Stage 3: Regularly status the schedule and communicate the changes to the client.

Having a plan is only part of the power of scheduling.  Create a baseline and show the slippage between any current ‘client owned’ activities and the plan. Using unbiased data to highlight issues will change behaviours – no one likes to be seen to be causing delays, particularly the project’s beneficiaries.

Stage 4: Raise a risk for anticipated future delays – manage the risk.

When you have a sense that the client is not going to meet their deadlines raise a risk and look for ways to manage the risk. If possible ask the client to help with the risk mitigation plan, which will give them some buy-in to help you be successful. This type of engagement also helps from a communication standpoint to better manage expectations. See more on risk management.

Stage 5: Raise an issue for an actual delay – manage the issue.

If the client ends up not meeting their dates, you have an issue that needs to be effectively managed. Issues management (problem identification and resolution) needs to be performed. Get your team, management, and stakeholders involved. Ask your manager for their input in resolving the problem that is now impacting your completion date. Get more accountability from your managers and the client’s managers to help resolve project deadline concerns. Your managers and sponsors are also the ones in a position to manage priorities to get the work done. If the problem cannot be resolved perfectly, at least you are continuing to manage expectations. See more on issue management.

Stage 6: Deal with contract issues contemporaneously.

If there is a need to make a contractual claim for the delay, make the claim immediately whilst the cause and effect are easily defined and keep the claim factual If the earlier steps in the process have been followed there will be no surprises and resolution of the issue can be achieved with the minimum of fuss or delay. See more on contractual dispute management.

Summary

Client induced delays are best avoided:

  • In commercial contracts, the ‘excusable delay’ (EOT) claim will inevitably damage the relationship and cause ill will – the effect of which can outweigh the benefits of the ‘claim’.
  • Internal projects don’t have the ‘claims’ option and may appear to be unreasonably held accountable for events and circumstances that are not within their control, but they do have control over the processes used to manage the project.

By utilising disciplined and proactive project management processes, you are more likely to avoid these problems and encourage the client to help you be successful by managing expectations and getting the client to be a part of the solution – not just the problem. It’s really just a case of applied stakeholder management!

Making Sense of Schedule Risk Analysis – Free Event

Mosaic Project Services is pleased to be supporting a free AIPM Project Controls SIG  (PC-SIG) meeting to be held at The Water Rat Hotel, 256 Moray Street, South Melbourne VIC, 3205: http://www.thewaterrathotel.com.au/

Date: Wednesday 20 November 2013,  Start 5.30 pm – Start (note earlier start time) Finish 7.00 pm –  There is no catering for the forum but interested participants are invited to pre and  post- forum drinks at the bar (after all it is a pub!!).

The agenda for the meeting is:

  • 17:30 Welcome to the AIPM SIG COP
  • 17:35 AIPM News – John Williams
  • 17:40 Project Controls Developments – Pat Weaver
  • 17:45 Presentation “Making Sense of Schedule Risk Analysis” – Tony Welsh
  • 18:45 Wrap up
  • 18:50 Close (after-meeting drinks/ dinner option)

The main presenter is Tony Welsh, President, Barbecana Inc. http://www.barbecana.com

Tony was one of the founders of Welcom (producer of Open Plan and Cobra) back in 1983.  He sold the company to Deltek in 2006 and has recently started a new company, Barbecana.

Barbicana

Tony grew up in South East London and holds degrees in physics from Oxford University and in operations research from the London School of Economics. His career began at Imperial Chemical Industries (ICI) under the direction of John Lawrence, a leading light in operations research (O.R.) and editor of the British O.R. Society journal. His work focused on sales forecasting, media scheduling, and measuring the affects of advertising.

Since 1980, Tony has been involved exclusively with project management software, for most of that time at the company he co-founded, Welcom. During that time he has been personally responsible for, among other things, the development of no less than four schedule risk analysis systems.

His paper will start with a brief discussion of the nature of uncertainty and how we measure it, the validity of subjective estimates, and why schedule uncertainty is different and more complex than cost uncertainty.  This will include an explanation of the phenomenon of merge bias.

It will go on to explain how Monte Carlo simulation works and why it is the only valid way to deal with schedule uncertainty.  Reference will be made specifically to uncertainty relating to task durations, resource costs, and project calendars.

The main part of the paper will deal with how to determine the input data, including correlations, and how to interpret the results, including estimated frequency function, cumulative frequency function, and percentile points.

The paper will conclude with a discussion of sensitivity analysis, its value, and the difficulty of doing it properly.

This event is a rare opportunity for Australian based project controls professionals in and around Melbourne to engage with one of the founders of the project controls profession, still active in developing and advancing our skills and knowledge.

To help manage numbers you are asked to register with AIPM at?  http://www.aipm.com.au/iMIS/Events/Event_Display.aspx?EventKey=VI131120&zbrandid=2139&zidType=CH&zid=5168408&zsubscriberId=505907810&zbdom=http://aipm.informz.net  (the event is free).  But as long as you don’t mind the risk of standing, pre-registration is not essential.

As the event sponsor, my hope is we have a really good turnout for the event and look forward to seeing you at The Water Rat – there’s plenty of street parking and the pub is on the #1 tram route.

The Schedule Compliance Risk Assessment Methodology (SCRAM)

SCRAM is an approach for identifying risks to compliance with the program schedule, it is the result of a collaborative effort between Adrian Pitman from the Australian Department of Defence, Angela Tuffley of RedBay Consulting in Australia, and Betsy Clark and Brad Clark of Software Metrics Inc. in the United States.

SCRAM focuses on schedule feasibility and root causes for slippage. It makes no judgment about whether or not a project is technically feasible. SCRAM can be used:

  • By organisations to construct a schedule that maximizes the likelihood of schedule compliance.
  • To ensure common risks are addressed before the project schedule is baselined at the commencement of a project.
  • To monitor project status, performed either ad hoc or to support appropriate milestone reviews
  • To evaluate challenged projects, to assess the likelihood of schedule compliance, root cause of schedule slippage and recommend remediation of project issues

Whilst the documentation is intensely bureaucratic, the concepts in SCRAM move beyond the concepts embedded in processes such as the DCMA 14 point checklist  to asking hard questions about the requirements of stakeholders and how effectively risk has been addressed before baselineing the schedule.

The SCRAM concept is freely available.  The SCRAM Process Reference Model (PRM) and a Process Assessment Model (PAM) documents are available for immediate download from: https://sites.google.com/site/scramsitenew/home

For more on schedule risk assessment and compliance assessment see: http://www.mosaicprojects.com.au/Planning.html#S-Risk