Monthly Archives: May 2016

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.

Advertisements

New Articles posted to the Web #47

BeaverWe have been busy beavers updating the PM Knowledge Index on our website with White Papers and Articles.   Some of the more interesting uploaded during the last couple of weeks include:

And we continue to tweet a free PMI style of exam question every day for PMP, CAPM and PMI-SP candidates: See today’s question and then click through for the answer and the Q&As from last week. You are welcome to download and use the information under our Creative Commons licence

The maturing or ‘agile’

kitten-yogaA deliberately provocative article on Linked-In asks the question is ‘Agile Dead?’; a discussion on how various aspects ‘agile’ invented by different individuals and groups are fading from prominence follows.  Agile is not my area of expertise but the article seems designed to generate attention without really saying anything new.

What the article did prompt in my thinking was the question ‘What is agile?’. Concepts vary from:

  • The Agile Manifesto (which is basically 101 common sense) created to overcome the failures of rigid IT development that required a 100% complete fully detailed plan before people really knew what the problem was (often referred to as ‘waterfall’ development but nothing like the original ideas in the waterfall concept).
  • Through to the agile anarchist community who’s mantra seems to be ‘trust us all of our teams are above average’ and we will make you really nice software without any discipline (a concept that ignores the mathematical fact that 50% of any group have to be below average….).
  • Then there are all of the various ‘agile’ methods from ‘Scrum’ to ‘XP’.

Ergo ‘Agile’ or ‘agile’ can mean virtually anything to anyone.  In contrast to all of these specific variants, I would suggest at its root ‘agile’ is a concept or philosophy rather than a methodology or process; useful philosophies rarely ‘die’.

What is emerging I believe is a gradual understanding that the false concepts of ‘command and control[1] and ‘certainty, based on a fully detailed plan[2] are slowly disappearing from management thinking (although there are still plenty of recalcitrant ‘fossils’ embedded in far too many management structures) – detailed planning months or years in advance of the work, done at a time where the work is imprecisely understood cannot control an uncertain future regardless of contract conditions and the exhortation of management. These ideas are slowly being replaced by an adaptive approach to projects that engages stakeholders and focuses on actually achieving the stakeholder’s objectives and realising benefits, ie, an ‘agile’ approach.

Every project and every project management system can benefit from some elements of ‘agile’ (which overlaps with many other concepts such as ‘light’, ‘lean’, and ‘last planner’. The key tenets seem to be:

  • involve your stakeholders,
  • trust your team,
  • don’t waste time planning in detail things you don’t have detailed knowledge of[3],
  • adapt to changing circumstances, and
  • wherever possible avoid a ‘big bang’ approach – iterative and incremental developments mitigate the risk of catastrophic failure.

The agile manifesto certainly highlighted these important concepts but it did not invent them. These elements of fundamental common sense are ignored in far too many situations. What the agile manifesto and the subsequent changes in attitude have done is refocus on the importance of people and relationships in any project.

On the ‘Agile front’, many of the ridiculous excesses promoted by consultants and experts are certainly fading into obscurity. Executives are learning that ‘agile’ is not a cure all ‘silver bullet’ it needs pragmatic management and proper planning the same as everything else, it just the way planning and managing is done that differs; for more on this see: http://www.mosaicprojects.com.au/PDF_Papers/P109_Thoughts_on_Agile.pdf

Certainly there has been a realisation that the agile anarchist’s concept of ‘trust us’ (and their abandonment of any pretence of strategic planning and documentation) really does not work. An appropriate degree of planning, coordination and documentation are essential to achieve success, particularly on larger projects and in the longer term when the inevitable updates and maintenance cut in.

In summary, if ‘agile’ is a philosophy that prioritises people over rigid process, and it will change and adapt over time; it’s not ‘dead’ but it is evolving into a pragmatic management process. Certainly some of the narrowly defined concepts and methodologies branded as ‘agile’ are failing and being abandoned as ‘passing fads’ and new adaptations are emerging, but that’s normal. The core underpinnings of the original Agile Manifesto are still alive and well.

___________________

[1] In the 1950’s Peter Drucker identified the need for a new way of managing ‘knowledge work’, see: http://www.mosaicprojects.com.au/PDF_Papers/P070_A_Simple_View_of_Complexity.pdf

[2] “All models are wrong, but some are useful” (Prof. George E.P. Box), and every estimate used in the plan is wrong to a greater or lesser degree, see: http://www.mosaicprojects.com.au/WhitePapers/WP1051_Cost_Estimating.pdf

[3] For more on ‘rolling wave’ planning see: http://www.mosaicprojects.com.au/WhitePapers/WP1060_Rolling_Wave.pdf