Free Book

Posted on 23rd March, by JimYoung in Blog, Book. Comments Off on Free Book

That’s right – after three years of steady sales, Whitcoulls Ltd, New Zealand book-sellers, tell me that local demand for my “Managing Murphy” textbook is flagging. Bugger, no more orders. I’ll have to postpone retirement, write another book or even get a real job. But rather than face the ignominy of a fire sale, I thought that you, my blog readers, would appreciate a free copy of this book while its content remains current. Yeah – today’s technical books, unlike history books, have a diminishing half-life as new ideas flourish exponentially. Actually, that’s not entirely true – history too is frequently rewritten.


This free book comprehensively explores the subject of contemporary project risk management.  There’s more here than most people would ever wish to know, but it might look good on your desk when the boss or risk-averse clients visit.  Anyway, please hit right here for your full colour copy.  Load up the printer with 432 pages of pristine white A4 paper if you intend to produce a hard copy.  Best do so using the paper and photocopier at your place of work, which is surely justified since part of everyone’s job is to manage projects – and big or small they all harbour risk that needs to be managed.  In fact, you would be irresponsible not to have this book on hand.  Let me know if the book is useful.  If you on-sell it, remember some koha for the writer pictured above in his office producing this very article.   When bound the hard copy might also help to solicit a confession or provide a most effective doorstop.


And here’s a small extract from this publication that tells you about the content for a helpful project risk management plan:

“A risk management plan is typically developed during the conception and development phases of our project and is updated by us as required during project execution.   Yes, it’s a living document that will need to be updated periodically.  Such a plan describes how risk management will be performed on our particular project.  It concerns the overall risk strategy and requires the development, implementation, monitoring and evaluation of appropriate risk response strategies.  Like other specific project management knowledge area plans, our risk management plan is typically published as a sub-set or appendix of our project management baseline plan.   It is important to clarify risk management roles and responsibilities, prepare budget and schedule estimates for risk-related work, and often to identify risk categories to help us with the methodical identification of risks.  It is also most important to describe how risk management will be done, including the assessment of risk probabilities and impacts.


The risk management plan explains how we project mangers and our project teams propose to manage risk on our project.  It provides guidance and requirements, and serves as a communication tool for those who wish to be informed of the project’s risk management approach.  The plan also provides specific guidance for our project team in all steps of the risk management process.  It documents the processes to be used throughout our project for identifying, analysing and managing risk.

The risk management plan might typically repeat the overall project purpose, goal and objectives, and depending mainly on the project’s size and complexity, would also address the following risk management items:

Methodology.  How will risk management be performed?  What principles and processes will apply?  How much risk management will be performed, taking into account the project’s priority, size, novelty, complexity and consequences if it fails?  Risk methodology is adapted and scaled to the needs of our particular project.  Low-priority and smaller projects usually warrant less risk management effort than high-priority and larger projects.  Keep in mind that project risk management needs to be cost-effective.

Roles and Responsibilities.  What are the specific risk management roles and responsibilities of key players?  Who will do what?  A Responsibilities Assignment Matrix (RAM) can provide a useful summary.  The RAM template allows us to allocate risk management responsibilities for our project, typically using “RASCI” definitions, where:

R = responsible. Those assigned to do the risk management work or for ensuring the work is done.

A = accountable. Those who are ultimately accountable for the proper completion of the work, and to whom the person responsible is accountable.

S = support. Those who can provide support to the risk management activity.

C = consulted. Those stakeholders whose opinions are to be sought and with whom there is two-way communication.

 I = informed. Those who are to be kept up-to-date on progress, with whom there is typically only one-way communication.

Sometimes other RAM designations might apply or be more appropriate, such as Driver, Approver, Contributor, Verifier, Signatory, and Omitted.  An “Others” column might include the Programme Manager, Project Director, Customer Project Manager etc.  The RAM needs to be customised to meet our specific requirements.  It provides  a basis for preparing detailed risk management job descriptions.


Other items likely to be addressed in our project risk management plan are:

Budget. What resources are needed and what is the estimated cost for undertaking our risk management process?  This cost associated with the provision of risk management and contingency planning is included in our project budget.  We should appreciate that this sum is an investment in saving time and money by avoiding or reducing threats and taking advantage of opportunities.

Risk categories. What main categories of risk will be relevant and therefore addressed on the project?  There are a variety of ways to classify or categorise risk. One very useful approach is to use the categories or objectives of scope, schedule, cost, and quality, while recognising their relative importance. To these we might add health and safety and benefits (ie, the rationale for the project as given in a business case). The aim is to have a comprehensive, consistent and coherent approach to risk identification.

Risk thresholds. What level of risk to each project objective will be acceptable? This will be influenced by the relative importance assigned each objective and stakeholders’ risk tolerance.  For example, if our project is time-driven, any schedule risk would be significant.

Risk analysis.  How will risk probabilities and impacts be determined?  What methods will be used for qualitative and quantitative risk analysis?  A declared standard for probability and impact is defined so the level of application is precise and similar for all involved.

Communications. What risk recording and reporting procedures and templates will be required?

Audit.  By whom, how and when will the effectiveness and efficiency of our risk management process be audited?

Glossary.  Clear definitions of project risk management terms may be needed to ensure their common understanding and our unambiguous communications.

In addition to these generic topics, and after risks are analysed, project risk management plans usually document some more project-specific risk factors, including:

Contingency plans are predefined actions that our project team will take if an identified risk event occurs.  For example, if we find that the release of a new software package is not to be available in time for use on our project, we might implement a contingency plan to use an existing, but older version of the software. Contingency plans are generally part of the risk management plan, but they may also be integrated into other parts of the overall project plan, perhaps as part of scope management or quality management.

Fallback plans are developed for those risks for which contingency plans prove to be ineffective. For example, a university graduate might have a main plan and a contingency plan on where to live after graduation, but if neither of those plans prove to be satisfactory, a fallback plan might be to live at home for a while.  Sometimes the terms contingency plan and fallback plan are used interchangeably, but in formal project management parlance, a fallback plan is what we implement if our contingency plan fails.  Fallback plans may not necessarily be prepared and published in advance.  They may be a work-around developed at the time.

Management reserves are provisions typically held by the project sponsor or funding organisation to reduce the risk of cost or schedule overruns to an acceptable level. For example, if a project appears to be off course because staff are inexperienced with the use of some new technology and our team has not identified this as a risk, our project sponsor may provide additional funds from the management reserve to hire an outside consultant to train and advise the project staff in the use of the new technology.  Contingencies, or contingency reserves as they are sometimes termed, are for identified risks, whereas management reserves are for unidentified risks of which there will always be some.  The management reserve is not normally used unless we identify new work.   Again, sometimes the terms are used interchangeably.  Also, the term reserve might be used with other modifiers such as budget or schedule reserve.”


Phew – if you managed to read all the way down to here, you must be interested.  Here are some slides on the subject that you may also appreciate. Also attached here is a risk list.






Comments are closed.


My latest thoughts on Project Management and life.

Business Analyst (BA) and Analysis

To survive or preferably thrive, organisations cannot stand still. They must evolve and progress to remain alive. Such evolution and progress requires projects. And...

Free Book: “Managing Smaller and Medium-Sized Projects” by Dr Jim Young PMP

I acknowledge with sincere appreciation the contributions to this book from numerous clients, student, colleagues, friends and project management practitioners. Their sometimes unwitting input...

The “Lean” Project

Lean is an often-used adjective in business these days, but there’s some confusion over its exact definition. In essence, the goal of Lean is...