Blog

Previously, we outlined five useful tips in Project Risk Management, and we then went on to discuss five essential tasks in Project Risk Management. In this article, we will complete the theme of “Things to know in Project Risk Management” by looking at what NOT to do in Project Risk Management.

Most Project Risk Managers have learned through years of laborious workshop facilitation and risk review meetings that their job is not one of glory or grandeur. It’s a bit like being an intelligence analyst in a war office. The Generals take all the glory while the foot soldiers gain ground but, without the intelligence analyst constantly checking the best way forward and looking out for potential pitfalls, the war would never be won, and no glory would be gained, by anyone. The same applies to Project Risk Managers. On a well-managed project, they will occasionally be thrust into the limelight but, by and large, they will carry on with their jobs without making a great fuss and the project will be hailed as a remarkable success on completion. Conversely, on a poorly managed project, the Project Risk Manager is likely to receive a bit more attention than he or she would really want. This is because on poorly managed projects things go wrong and fingers get pointed. There are numerous very easily identifiable reasons why things may go wrong on a project, and most of them will come down to inadequate planning and preparation. But, rather than looking inwards, many project leaders will try to lay blame on the “unknown”. In other words, they will say the project failed because of certain unanticipated events, and this is where fingers will start to shift in the direction of the Project Risk Manager. It is therefore crucial for Project Risk Managers to prepare for this in two basic ways:

• Get the full support from your Project Manager to designate risk ownership, where necessary, throughout the entire project team.
• Examine the project execution plan for gaps and weaknesses, and register all risks associated with these shortcomings.

Notwithstanding these basic preparatory requirements, there are also certain essential tasks that need to be carried out in order to keep your project risk management process controlled and effective. These were discussed in our previous article, titled: 5 Essential Project Risk Management Tasks.  What we now need to consider are the things that need to be avoided in Project Risk Management. These are numerous, but the most important things NOT to do, are as follows:

Do not attempt to manage risks that are beyond your scope or control

Every project needs to have a defined scope of work, budget and schedule. This even applies to projects that fall into the “Agile” category. Albeit in this case, defined work scopes, budgets and schedules tend to be more flexible and incremental than in traditionally structured projects. In any event, every project has boundaries and this includes boundaries on risk exposure. It is often the case that risks will be added to a project risk register just because they don’t have a “home” elsewhere. This can be highly detrimental to both the project and the entities exposed to these risks. It should be made clear to all concerned that the risks being managed by a project are only those that affect the project’s objectives, either in terms of project delivery, or the performance and safety of the project’s end-product. All other risks need to be transferred out, and managed by those responsible for safe-guarding the integrity of assets which are neither within the project scope nor remit of responsibility (see: 5 Tips in Project Risk Management – Tip #2).

Do not populate your risk register with irrelevant “perceived” risks

Risk registers are constantly at risk of being over populated with irrelevant risks. Project leaders and clients alike often hold the view that if a project risk register does not contain hundreds of risks, then the project is not being properly managed. This is not necessarily the case as, while all projects are always exposed to multiple risks, many of these risks are already captured within the prerequisite project plans, procedures and deliverables. Project Risk Registers should only contain risks that are not being formally managed elsewhere in the project. In most projects, there will be a mandatory requirement for numerous technical and safety assurance studies to be carried out. These include (to name but a few) HAZID, HAZOP, SIL, EIA, FEHA, EERA and SIMOPS studies which, to many, may just be a meaningless list of technical acronyms, but rest assured that these are all highly detailed deliverables of a technical risk assessment nature. A project risk register should be the exclusive domain of all risks that are not captured in the project plans, procedures and deliverables. In doing so, it is important to resist the urge to make up the numbers in your risk register by populating it with irrelevant, or “perceived”, risks. These may include risks which are outside of your scope and control, as discussed in the previous point above, or they may include risks which are real on other projects, but not on yours (see: 5 Tips in Project Risk Management – Tip #4).

Do not over-complicate your risks

Do not spend excessive hours trying to find complexity in your risks where there just isn’t any. Sure, some risks are quite complicated, while others just seem to be, but generally risks can be broken down into three relatively simple components: Threats (or Opportunities), Events and Impacts. When assessing any risk, start by asking yourself, “What is the main event I am looking at here?” Once you’ve established that, ask yourself, “What could cause this event to occur?” and, finally, ask yourself, “What impact will this event have on my objectives?” As a very basic example, consider the event of system hardware failure during testing. Now look at what could cause the failure of that hardware (in other words, look for the threats which could result in the risk event occurring). These could be numerous, ranging from incorrectly specified components, to poor assembly and installation, to inadequate preservation of the hardware materials. Finally, what are the impacts of the hardware failure? Again, these could be numerous and, depending on the type of hardware you are dealing with, could range from minor performance issues, to complete system damage, to multiple human fatalities. The key point here is to break each risk down into its three core components, so that the risk can be properly understood and effective mitigations established to help reduce both the likelihood of risk occurrence, and the severity of the risk impacts, should the risk still occur (see: Describing Risk: Accurate Description = Better Management).

Do not try to jointly manage opportunity risks and threat risks

Opportunity risks and threat risks need to be managed separately. Without this in place, Project Risk Managers run the risk of disrupting well thought out and established project execution plans. On every project, clients, contractors and members of your own team will come up with proposals on how to complete the project faster, cheaper and with improved performance. While these proposals should not be ignored, they do need to be assessed and managed as a separate process to the threat risks which occur on projects on a day-to-day basis. In an ideal world, this would be done by a team of project integrity specialists, working in parallel with the project delivery team, continuously reviewing all elements of the design basis, execution plan, schedule and budget to ensure the project is being executed in the best possible manner to produce the best possible result. Unfortunately, not many project teams have the luxury of engaging a dedicated team of integrity specialists, and the best most of us can hope for is a periodic peer review of our project progress. Even so, all opportunities still need to be treated as potential deviations from the plan and, as such, they need to be assessed and controlled in the same way any other change to project scope, budget or schedule is managed; through a formal Management of Change process. The key difference between managing threat risks and opportunity risks is that management of threat risks is the process required to keep a project on plan, whereas the management of opportunity risks is the process required to knowingly deviate a project from plan (see: Threat Risks vs. Opportunity Risks: Are they really the same thing?).

Do not confuse impact mitigations with probability mitigations

Risk managers and owners often fall into the trap of thinking of risk mitigations as being mitigations which can be applied to the risk as a whole, and don’t consider which element of the risk each mitigation affects. In most cases, being able to effectively mitigate the probability of risk occurrence should be a risk owner’s highest priority, while mitigating the impacts is what you have to do if the risk event still occurs. However, it is also possible to mitigate the probability of impact occurrence after a risk has already occurred. This is where things can get a bit confusing, and here it helps to keep a clear picture of the three basic risk components in your head. There are two ways to mitigate the impact of a risk, one is to control the likelihood of the impact occurring, and the other is to control the effect of the impact should it still occur. Both should be considered as impact mitigations, as they both deal with the potential impact of a risk that has already occurred. Probability mitigations deal with the likelihood of risk occurrence and aim to prevent a threat from triggering an unwanted event (or, in the case of opportunity risk, aim to take advantage of an opportunity to trigger a desired event).

For more information about our project risk management services and software, or if you just want to express your own views on the subject, please feel free to get in touch via our “Contact Us” page.

A short while ago, I read through a presentation which seemingly tried to convince me that the only difference between threat and opportunity risks was the sign of the impact. That is, threat risks result in negative impacts and opportunity risks result in positive impacts.

This, along with another statement in the presentation which read, “Not identifying and capturing opportunities means GUARANTEED FAILURE” (in bold-caps no less) disturbed me to such a degree that I finally decided to crawl out of my risk management closet and publish my own take on these two assertions.

Firstly, let me say that I am in no way trying to discourage the pursuit and taking of opportunity risks. Society, industry and life in general would just not be where it is today were it not for mankind continuously seizing opportunities and making the most of them. Many failed, but many also succeeded, and this is what has kept us evolving and developing since we first emerged as the confused, knuckle-scraping homo-sapiens that we were some two hundred thousand years ago.

However, seizing opportunity risks does, in my opinion, need to be exercised with some degree of caution, and not identifying or capturing these opportunities certainly does NOT result in guaranteed failure. So, to say the only difference between threat risks and opportunity risks is the sign of the impact is, I find, a rather simplistic and misleading statement.

Depending on the nature of the venture being undertaken, one will generally try to adopt a style of management which, hopefully, best suits the objectives of that venture. The more complex and valuable the venture, the more conservative the management style (generally). This corresponds directly with how risks are managed in these ventures. Opportunity risk is a good thing (in that it suggests a positive outcome). However, it is also a deviation. In large and complex projects, deviation is more often than not a bad thing. For example:

Assume we are about to commence an activity in which the project team has planned for, and secured, the use of specialised installation equipment available on a rental basis, to commence work on the planned date. The team then finds out that some technically superior equipment has become available which can do the job sooner, faster and at a lower rental cost. It would make sense to take advantage of this opportunity would it not? However, changing equipment at this stage of the project results in several new threat risks which now need to be considered, such as:

• Carrying out the work with different equipment is likely to require a change in execution procedures to ensure the new equipment can complete the job safely, efficiently and within project quality standards.
• Carrying out the work with different equipment is likely to require a review of operator certification and may result in re-training requirements.
• Carrying out the work with different equipment may result in site access and security issues.
• Commencing the work ahead of schedule may result in multiple interface clashes with other work scopes and schedule activities.
• Completing the work ahead of schedule may result in preservation issues if the original plan was to hook-up, commission and energise the installed materials immediately after the activity was complete.

All of this would necessitate a formal Management of Change process to be undertaken with a review of the new equipment specifications, revisions to technical documentation and procedures, re-evaluation of operator credentials, another site survey to be conducted, a review and revision of the project schedule, identification and coordination between all interfaces etc. If, at any point during these revisions and reviews, it became evident that more serious threat risks were now exposed, the project would have to consider scrapping this opportunity and reverting to the original plan which, if any hasty decisions had been taken in trying to exploit this “opportunity”, could result in the original plan no longer being viable.

Now, as I said earlier, I’m not trying to pour cold water over the enthusiasm for embracing opportunity risk, far from it. I firmly believe that projects should grasp opportunities wherever they can, but this needs to be done in an environment where the opportunity risks can be properly evaluated, planned, controlled and managed without disrupting existing project activities. Attempting this during the execution stage of large, complex projects with multiple interfaces and overlapping activities generally opens up a very large can of worms in my experience. For these types of projects, I maintain that the best way to achieve project success is by sticking to the old mantra of: “Plan the work, and work the plan”.

Even though opportunity risks may share the same basic ISO 31000:2009 management process as threat risks (see process flow diagram at the top of this article), the way in which opportunity risks need to be assessed and managed within this process is significantly different from the way threat risks are assessed and managed.

For more information about our project risk management services and software, or if you just want to express your own views on the subject, please feel free to get in touch via our “Contact Us” page.

In our previous article, where we discussed 5 Tips in Project Risk Management, we focussed on five of the most important things in Project Risk Management that need to be understood to make this process faster, simpler and more effective. In this article, we will take this one step further, and consider 5 essential project risk management tasks that need to be undertaken in every project to significantly improve the effectiveness of Project Risk Management.

By now, you will have established the parameters for your Project Risk Management process by applying the tips provided in our previous article. These were:

1. 1. Understanding the key factors determining success or failure of your project
   2. Knowing the boundaries of your scope
   3. Describing your risks accurately
   4. Eliminating irrelevant “perceived” risks
   5. Establishing realistic and achievable risk mitigations

You are now in a good position to start managing your project risks. However, every project needs structure and, similarly, each process within every project needs its own sub-structure. In Project Risk Management, this sub-structure comprises several prerequisite tasks which are required to keep the overall project risk management process controlled and effective. The number and types of tasks may vary from one project to another but, by and large, risk management processes in all projects need to apply the following five tasks:

Have your risk register set up at project commencement

Your project may be limited to a single, simple scope of work, or it may run over many phases, covering multiple complex scopes of work. Either way, you need to have your risk register set up and ready to go from the minute you start your project. Without this, you will be playing catch-up from Day 1, and will probably also be exposed to risks that may have already occurred. They say hindsight is 20/20 vision, and “they” are not wrong. The problem with this is that you end up spending most of your days trying to fix what you can only now see in hindsight. It would be so much better if you only had to focus on what is coming up, rather than trying to fix what has already past. While having your project risk register established from the get-go may not provide you with full 20/20 vision in advance, it will certainly help in keeping you looking forward, and spending less time dealing with unforeseen events that have already occurred. Bear in mind though, that it’s neither realistic nor practical to have a fully populated risk register from the outset. No single project is identical to another and, while you may be able to populate your register to a large degree with risks from multiple sources in advance (through Lessons Learned, Previous Experience, Expert Opinion etc.) new risks will continuously crop up as your project progresses.

Establish your team of responsible risk owners from the outset

Every member of your project team should be fully aware of their respective roles and responsibilities. However, knowing which risks, or more specifically which risk categories, are the responsibility of which team members is not something that is automatically defined, or immediately obvious, on any project. When kicking a project off (traditionally through a project kick-off meeting) one of the topics covered should be the designation of risk ownership. Depending on the size and complexity of the project, you may elect to have anything from one, to most, of your project team designated as risk owners. The important thing is to designate these risk owners from the outset, and be clear about the types of risks they will be responsible for. This makes the job of the Project Risk Manager a lot easier, as risks can be automatically assigned to risk owners based on pre-defined criteria such as: Project Phase, Scope, Discipline, Location, Activity or Department. In addition, with the risk management roles and responsibilities established and clearly defined up-front, there is less chance of risk owners being able to shirk their responsibilities by claiming they were either unaware of a risk being their responsibility, or of the risk even existing.

Hold regular risk review workshops

While having a populated risk register and designated risk owners in place at project commencement are essential components in successfully managing project risks, a risk register should never remain static. If it does, it means your risks are just not being managed. Risks will come and go, and the effect these risks have on your project depends entirely on how well they are managed. Project Managers and Risk Managers alike need to manage their respective responsibilities by keeping themselves informed and aware of all possible project impact events, at all times. Unfortunately, this inevitably means holding numerous workshops, and even more meetings. Now, holding too many meetings and workshops can often be counter-productive, but some of these are essential to the successful outcome of a project, and risk review workshops are one of these. However, you do need to structure the frequency of your risk review workshops in line with your project schedule and complexity. Just because some “expert opinions” recommend holding a risk review meeting every week, does not mean that this is necessarily right for your project. Project and Risk Managers should certainly be reviewing their project risk registers on a relatively high frequency basis but running workshops, which takes up precious time and resources, should be done selectively, at key junctures in the project schedule.

Associate parent and consequential risks

Risk Management can be made a lot simpler if one recognises the hierarchy of risks, and their relationship to one another. This is closely related to being able to describe a risk accurately (see Tip #3 in our previous blog post) but is more about recognising how the relationship between risks can be used to aid risk mitigation. If a risk occurs as a result of another risk, this is called a “Consequential Risk” and, if the occurrence of a risk produces other risks, this is called a “Parent Risk”. It is often the case that several consequential risks may arise out of one parent risk. In this case, adequately mitigating the parent risk may also mitigate all of its consequential risks. So, by identifying and linking all consequential risks back to their respective parent risks, one is generally able to manage several risks at once, through a single set of mitigations applied to the parent risk.

Ensure mitigations are implemented timeously

In our previous post on 5 Tips in Project Risk Management – Tip #5, we spoke about the necessity of applying S.M.A.R.T. measures when identifying and implementing risk mitigations. The “T” in S.M.A.R.T. stands for “Time-Bound”. This means all mitigations should have time constraints against their implementation and completion dates. If risk mitigations are implemented at the wrong time, they may end up being completely ineffectual. This applies to implementing mitigations both too early and too late. If implemented too early, their effect may be significantly reduced by the time the risk event occurs and, if applied too late, well… we all know the expression “Closing the barn doors after the horse has bolted”.

For more information about our project risk management services and software, or if you just want to express your own views on the subject, please feel free to get in touch via our “Contact Us” page.

Project Risk Management is often treated as the “Brussel Sprout” of Project Management. It is the vegetable no one wants to eat but, without it, the meal (read “project”) is just not as healthy or as complete as it should be. In fact, it is actually quite a bit more than that. A project without effective risk management is a project that is likely to fail. Notwithstanding this dire outcome, few projects put enough effort into managing the risks that are inherent in every one of them, and even fewer project team members actively and effectively manage the risks on their projects. This is often due to the fact that Project Managers and Project Leaders find most of their time is taken up fighting figurative fires in trying to deliver the project, attending client and contractor meetings, chasing deadlines, resolving design and contractual issues etc. They therefore either delegate the responsibility of project risk management to a junior colleague, or they hold one risk review workshop, compile a risk register and then forget about it for the rest of the project.

Unfortunately, this approach is the very thing that results in Project Managers and Project Leaders finding that most of their time is taken up fighting fires. Without effective Project Risk Management, projects are likely to remain in a continuous state of turmoil, and constantly bordering on chaos. However, by recognising the need for effective Project Risk Management, and understanding that this will make the project a lot easier to manage, Project Managers and Project Leaders can make their own lives (and those of their clients, stakeholders and sponsors) a lot less stressful.

One of the keys to this is not to get overwhelmed by the prospect of managing hundreds, or even thousands, of “unmanageable” risks on your project. The number of real day-to-day risks on projects does vary significantly, depending on project size and complexity, but these seldom exceed one hundred, even on highly complex mega-projects. The reason for this is that most of the risks are already managed through the defined project execution processes and deliverables. In Project Risk Management, it is important to identify the risks which are not covered through the formal project execution processes and deliverables, and manage those risks separately, through a dedicated project risk management process. This process can be greatly simplified by applying the following five Project Risk Management tips:

Understand the key factors which will determine the success or failure of your project

This will help you prioritise and focus on managing the risks that may have a significant impact on the outcome of your project.

Know the boundaries of your scope

This will help you eliminate those risks which are either not within your remit, or over which you have no control. These risks should be completely removed from your risk register or, at the very least, transferred to the relevant external parties who are responsible for their management.

Describe your risks accurately

If the risks in your risk register have been poorly described it will be difficult to manage them, as you may not know their cause, or the effect that they may have on your project. An effective way of describing risks is to define them as: “The threats (or opportunities), and events that may arise as a result of these threats (or opportunities), resulting in consequences which may affect the objectives of your project”. The potential consequences of a risk may be included in the risk description, but should be separated for purposes of mitigation identification. By describing risks in this way, you will be better able to identify mitigations that deal with the probability of risk occurrence, and mitigations that deal with the risk impacts, separately. For more information on the importance of accurately describing risk, see our previous blog post on this subject at: www.project-risk-manager.com/blog/describing-risk/

Eliminate irrelevant “perceived” risks

Many risk registers are populated with risks which are either irrelevant to the outcome of the project, or have no basis in reality. When running risk management workshops, or reviewing risk registers, it is important to keep an eye out for the “alarmist” risks. These may be risks like: “Rapid deterioration in weather conditions, resulting in a squall blowing through offshore facilities during installation activities, resulting in property damage and possible fatalities”. This is a very valid risk for projects being executed in areas which are prone to these types of weather condition but, if the project is being executed in a benign weather area, or at a time of year when there is a guaranteed calm weather period, then this risk has no place in your risk register.

Establish realistic and achievable risk mitigations

Having your risk register populated with accurately described, and relevant, risks is all good and well but, if the mitigations identified to manage these risks are neither realistic nor achievable, then the benefit of having identified and registered these risks in the first place is seriously undermined. A key to risk mitigation identification is to ensure they are S.M.A.R.T. In other words, all risk mitigations should be: Specific, Measurable, Achievable, Realistic and Time-Bound.

For more information about our project risk management services and software, or if you just want to express your own views on the subject, please feel free to get in touch via our “Contact Us” page.

In the first of our blog posts on this subject, we looked at three of our Top Ten Project Manager Traits. Those were: Understanding, Planning/Foresight and Adaptability (see: www.project-risk-manager.com/blog/project-manager-traits-part-1).

Last week we looked at the next three character traits that make a good Project Manager which were: Attention to Detail, Communication and Passion. (see: www.project-risk-manager.com/blog/project-manager-traits-part-2).

This week we will consider the final four of our “Good Project Manager” character traits, which are:

Logic

Often underestimated, or taken for granted, logic is one of those character traits that most people pride themselves on having. But, so often logic is overridden by emotion, prejudice or preconception that the extent to which logic is usefully applied in decision making is greatly reduced. Good Project Managers have an ability to consistently apply logic by filtering out emotion and prejudice, and questioning preconceptions, whenever they are faced with decision making challenges. One could argue that being a good decision maker is one of the character traits of a good Project Manager, and this would not be wrong. However, an essential component in being a good decision maker is to have a strong grounding in logic. I have therefore opted to use the character trait of logic in place of good decision making in my top ten character traits as, without having a good grounding in logic, it is very difficult to be a good decision maker.

Resolve

Good Project Managers need to be resolute. Projects do not deliver themselves, and they are seldom delivered without a determined effort. Every project is likely to suffer a setback of some sort at some point, and most projects will suffer several setbacks at several points during their execution. Without resolve (or determination) many Project Managers will fail to achieve their project’s objectives while others will simply lose their ability to manage the project effectively. When faced with a setback, a good Project Manager will stay motivated and look for the best way out. There’s an old golfing term that goes; “It’s not about how well you play, it’s about how well you recover”. This is as true in golf as it is in projects. The world’s best golfers are the ones who consistently get themselves out of the rough, or out of bunkers, and still get down in under par. This doesn’t just require skill, it requires resolve. The same is equally true of the world’s best Project Managers. They do not let setbacks get them down, and they actively find ways to turn setbacks into positive outcomes. Few people will sit up and take note of a project that runs its course without hiccup but, when a project is fraught with challenges and setbacks, and is still delivered on schedule, within budget and without any LTI’s, that is when it stands out from the crowd. Now that is not to say a project that ran its course without hiccup was not well managed, it most certainly must have been. However, delivering a project without hiccup is a fairy-tale scenario, and we all know that delivering projects is not the stuff of fairy-tales.

Resilience

Being a Project Manager is sometimes like being a punching bag. Everyone wants to have a go at you at some point. Normally it’s the client, often the contractor and occasionally even your own sponsors! Good Project Managers are able to take the punches but, unlike punching bags, they occasionally punch back. No project is perfect and therefore no project is free from criticism. A project’s antagonists normally only have one person they need to take aim at, and that is the Project Manager. If a Project Manager wants to deliver their project successfully, they need to be able to take criticism from all angles and bounce back from it. This goes hand-in-hand with being resolute, but it is also about having the confidence in yourself, your plan and your team to not only withstand unwarranted criticism, but to adapt where criticism is warranted. When criticism is unwarranted, good Project Managers will defend their position, but not blindly or unconstructively. This is where the other “Good Project Manager” character traits of Understanding and Planning come into play. A good Project Manager will understand the drivers of their antagonists, and will have confidence in their own plan to be able to react productively and effectively. By doing so they will not only keep their project on-track, but may also win over the confidence of their critics. Conversely, if the criticism is actually warranted, then the character trait of “Adaptability” comes into play. As discussed in Part 1 of this blog, if change is required, good Project Managers are able to do so quickly and efficiently, with minimal disruption to their project.

Discipline

Sometimes also described as being “Methodical”, but having discipline is so much more than just being methodical. In Part 2 of this blog (under “Attention to Detail”) I mentioned that projects are multi-faceted affairs, and keeping on top of them not only requires having a good team around you, but it also requires a good deal of discipline. It is very easy to get side-tracked on projects by whoever is shouting the loudest, and this is where good Project Managers need good discipline to keep their projects on track. Staying focussed, logical, resolute and resilient all require a good deal of discipline so, without discipline, these character traits can be seriously undermined. It is not enough to have any one of these qualities in isolation, as being a good Project Manager means having all the necessary character traits required to successfully deliver your project. Discipline is the glue that holds a project together and, in many ways, is also what binds the other character traits into a cohesive force that makes a good Project Manager.

For more information about our project risk management services and software, or if you just want to express your own views on the subject, please feel free to get in touch via our “Contact Us” page.

Last week we started looking at the Top Ten Project Manager Traits and, in our first blog on this subject, we considered the first three of those traits which were:

Understanding, Planning/Foresight and Adaptability (see: www.project-risk-manager.com/blog/project-manager-traits-part-1).

This week we will consider the next three traits which are as follows:

Attention to Detail     

Another cliché you will often hear in Project Management is, “The Devil is in the detail”. This is one cliché that I happily embrace, not only because it is true, but because of how often it occurs on projects. If there is one characteristic that has saved many a project from disaster, this has to be right up there. Good Project Managers have an almost uncanny ability to spot things that either don’t fit, or need to be exploited. It could be a contractual clause, an element of a safety plan, a schedule activity, design detail or just a figure in a report. Project Managers are seldom specialists in any one field, but what makes them good Project Managers is their ability not only to see the big picture, but also to spot the nuggets and nails in the woodpile. Projects are multi-faceted affairs, and keeping on top of them requires support from a good team of discipline specialists. However, the Project Manager is responsible for making sure that each of the disciplinary elements link together in the right formation, at the right time, all the time. Spotting a detail in any one of the discipline deliverables which may have a legal, logistical, contractual, design, safety, or other impact is not something that can always be caught at discipline level. Good Project Managers are aware of this and are therefore always on the lookout for the small things that can either trip up or benefit a project. One of my ex-colleagues (who also happens to fall into the “Excellent Project Manager” category) expresses this as “having a healthy level of paranoia”. While this may not be quite the same thing as having good attention to detail, it certainly helps in keeping one’s attention on the detail!

Communication

Good communication on projects is paramount. Be it communication between your clients and contractors, your own team, your sponsors, or any other stakeholders on the project. The bottom line is: Good Project Managers are good communicators, and that does not mean they are good talkers. There is a big difference between good talkers and good communicators. Good communicators do not waffle. They stick to the facts and they stick to the information that needs to be communicated. Period. One can often spot a bad Project Manager just by noting how much they say, and how much of what they say is neither relevant nor factual. That’s not to say there’s not a time or a place in Project Management for irrelevance, non-factual anecdotes and speculation. There certainly is, but those times and places are generally reserved for social, team-building, or other events conducive to more colourful discourse. Project meetings, briefings and reviews need to be relevant, factual and to the point. One of the luxuries projects seldom have is time, and few things are more time wasteful than sitting in a meeting where you are either not needed or the subject matter is neither relevant nor factually based. In Part 1 of this blog, I mentioned that one of the key principles in project management was to “Keep it Simple”. This principle extends to communication. The simpler you keep it, the more your communication will be understood, remembered and actioned correctly.

Passion

Otherwise known as “Energy”. Projects thrive on energy, and a Project Manager who is passionate about their assignment will impart this energy to the rest of their team, clients, contractors, sponsors and other stakeholders alike. There is no substitute for passion. Look at any successful sports team, venture, business or social event and the common denominator for its success (necessary skill sets aside) will be the passion, or energy, of the team and individuals involved. Not only does passion instil energy, but it also instils belief, and belief is an essential ingredient in the successful outcome of any undertaking. People will go to great lengths to highlight their educational qualifications, skills and experience on their résumés, but whenever I have interviewed anyone for a job, one of the first things I look for in them is their level of enthusiasm/passion/energy. Everything else can be learned, but passion comes from within. If a person is not passionate about what they do, that doesn’t mean they won’t succeed, as they may still have the necessary skills and experience to get them there, but they will struggle to excel. This attribute is even more important in Project Managers, Business Leaders and Team Sport Captains, as it is their passion that acts as one of the primary motivators for the rest of their team, and instils the belief of success not only in the team but also in everyone else involved, be it client, contractor, sponsor or any other stakeholder.

Next week we will look at the final four of my top ten Project Manager character traits, which are: Logic, Discipline, Resolve and Resilience.

For more information about our project risk management services and software, or if you just want to express your own views on the subject, please feel free to get in touch via our “Contact Us” page.

For the next three weeks, we will be deviating slightly from our usual general topic of Risk Management, and will consider instead the topic of: Top Ten Project Manager Traits.

Projects can generally be categorised as either simple or complex but, more often than not, those that start out being relatively simple can rapidly become complex. A good Project Manager knows this and, as such, embraces two key project management principles: Keep it Simple and Adapt to Change. That alone, however, does not make for a good Project Manager, but it will certainly stand them in good stead when it comes to managing most projects.

Over the past 26 years, I have had the pleasure (and occasional displeasure) of working with some of the best and worst Project Managers in the Engineering & Construction industry. One of the best Project Managers I worked with was on one of my more recent assignments where we were challenged to deliver an offshore green-field gas production facility, from Concept to First Gas in 18 months. This was a one-billion-dollar budget project. Needless to say, it was an extremely demanding schedule which, unfortunately, we didn’t quite achieve. But that was not for want of trying! If we had, it would have no-doubt been a new world record but, in the end, we did deliver First Gas in just over 24 months from commencement of FEED and, in doing so, won several achievement recognition awards ranging from various Health and Safety awards to the overall “Marginal Field Development of the Year” award. Drawing on this, and all other projects I have been involved in over the years, I have condensed what I believe to be the top ten character traits that make for a good Project Manager. Due to the length of this article, I have split it into 3 parts. This week we will look at the first three “Good Project Manager” character traits, which are as follows:

 Understanding

Part of being a good Project Manager means needing to have a good understanding, not only of the project they are responsible for, but of everything associated with the project. From understanding the project scope, budget and schedule, to the boundaries of their responsibilities, to the drivers of their clients and contractors, to the requirements from every member of their team. It is essential to have a good understanding of all of this as it will help Project Managers stay in control and separate what they can, and should, be managing from what they can’t, and shouldn’t, be managing. This may seem like an obvious statement, but I have come across many a Project Manager who understands their project scope, budget and schedule extremely well, but does not have a clue what their primary stakeholders’ priorities are. These priorities will normally always include keeping the project within budget, staying on schedule and not incurring any health and safety incidents, but there are often more subtle (and some glaringly obvious) issues that need to be understood and managed as well. These include political agendas, community agreements, internal conflicts, design preferences and vendor bias, to name but a few. When dealing with these issues, it is crucial for the Project Manager to understand:

1. The boundaries of their responsibilities,
2. Their contractual, legal and social responsibilities and,
3. Which issues need to take priority and be managed within their remit.

Whenever there is a lack of clear understanding about a Project Manager’s roles and responsibilities, it becomes very easy for them to get drawn into issues that are outside their remit. This may, on occasion, save the day for someone but, more often than not, it only serves to take the Project Manager’s focus off key issues that are their direct responsibility, and potentially disrupt the project as a whole.

Planning/Foresight

There are many clichés thrown about in Project Management. So much so, one could probably write a book about them. One of the most common I’ve heard is: “Hindsight is 20/20 vision”, and this is normally uttered just after something has gone wrong, which is an indication that either the plan was not followed, or it was flawed to start with. The best Project Managers I have worked with try to anticipate key events in advance, and look for ways to control the threats and exploit the opportunities without jeopardising the overall project plan. They give themselves the best chance of succeeding at this by investing time upfront to ensure they have all of their critical project controls in place prior to kicking a project off. This includes (but is not limited to) having a detailed and approved project schedule, deliverables register, resource plan, cost control register and execution plan. They also always keep their project risk register relevant and up to date. Most importantly, however, they make sure their plan is robust, and stick to the plan as far as possible.

Adaptability

The problem with projects is that they change. Having a plan, and sticking to it, is great. But no plan is perfect and no project is static. Things will change, and good Project Managers know how to adapt to these changes with minimal disruption to their project. This is why it is imperative to have a concise (and not overly complicated) Management of Change procedure in place on every project. Most projects will have one but, time and again, projects will still fail because their changes were not properly managed. This is either because the Management of Change procedure was not followed correctly, or the procedure itself was flawed. I’ve seen MoC procedures that are so complicated you need degrees in law, logic and literature just to follow one. Successful projects will generally have a concise and easy to follow MoC procedure. Not only that, but the process of applying and approving changes will be as straight forward as possible, and the same process will apply for client and contractor alike. How many times have you heard, “Just get on with the changes, and we’ll sort out the paperwork later”? This will inevitably be the case when the MoC procedure is either too complicated, or the approval process too drawn out, to control the changes while executing them in parallel. Good Project Managers keep on top of changes by acting on them quickly and efficiently, with the help of a good Management of Change procedure. In doing so, they ensure their project can adapt to changes with minimal impact to the project’s objectives and Key Performance Indicators.

Next week we will look at the following three “Good Project Manager” character traits, those being: Attention to Detail, Communication and Passion.

In the third week, we will consider the final four of my top 10 character traits, which are: Logic, Discipline, Resolve and Resilience.

For more information about our project risk management services and software, or if you just want to express your own views on the subject, please feel free to get in touch via our “Contact Us” page.

In this post, we will delve into one of the technicalities of Qualitative Risk Analysis and that is: Risk Matrix Sizing. This is a topic which, surprisingly, has occasionally resulted in heated debates between Risk Management Professionals. So, not being afraid to wade into the fray myself, this is my take on the subject.

In Qualitative Risk Analysis, we generally rely on the use of a risk matrix to define the severity of a risk. This is done by ranking the probability of risk occurrence against the potential impact of the risk. The product of Probability x Impact gives us a value which defines the overall severity of the risk. Now, some may argue that this is actually a form of Quantitative Risk Analysis and, in a sense, it is. After all, we have just used the product of two values to determine the acceptability level of a risk, which is essentially a quantitative risk analysis approach (see our previous post on this subject: https://www.project-risk-manager.com/blog/qualitative-and-quantitative-risk-analysis/).

The difference here though, is that instead of using verified data to establish the values for Probability and Impact, we have applied subjective data. In other words, in Qualitative Risk Analysis we establish the Probability and Impact values based either on historical data, expert knowledge, past experience or, at worst, just plain old gut feel. And this is what really underpins the debate around the importance of risk matrix sizing.

The bottom line in risk management, be it using Quantitative or Qualitative Risk Analysis techniques, is that all risks need to be managed to within a defined range of acceptability. In Technical Safety Quantitative Risk Analysis, this will be a number which defines the acceptable frequency of fatalities per year. (Generally anything over 1 x 10^-3, or 1 fatality every 1000 years, is considered unacceptably high). In Qualitative Risk Analysis, however, the range of acceptability falls within the “Green Zone” of a risk matrix.

Now, if you’re using a 4x4 matrix, this means the upper extremities of acceptability are either when the probability of risk occurrence is “Possible”, and the impact is “Low”, or the probability of risk occurrence is “Rare”, and the impact is “High”.

Alternatively, if you’re using a 5x5 matrix, this means the upper extremities of acceptability are either when the probability of risk occurrence is “Possible”, and the impact is “Very Low”, or the probability of risk occurrence is “Rare”, and the impact is “Medium”.

So, what’s the difference?

It all comes down to how precisely you’ve defined the Probability and Impact ranges and, more importantly, how accurately the person managing the risk is able to rank each risk’s probability and impact within the defined ranges.

More often than not, risk matrix sizing ends up being a matter of personal preference. As long as a risk is ranked accurately enough to determine what measures are required to bring the risk into the acceptability range (or “Green Zone”) then, whether you use a 4x4 matrix or a 5x5 matrix makes little difference. However, using matrix sizes smaller than 4x4 or larger than 5x5, can actually be detrimental to effective risk management. This is because the range of uncertainty becomes too constrained in the one case and too vague in the other.

Because risk matrices are used in Qualitative Risk Analysis, it is important to remember that they are there for subjective guidance, and not to provide you with definitive Quantitative risk ranking data. In the case of trying to use a 3x3 matrix, it becomes difficult to gauge where the boundary between Acceptable and Unacceptable lies and, when trying to use a 6x6 matrix, the distinction between a risk impact of “Very High” or “Severe”, or risk probability of “Highly Probable” or “Certain”, becomes largely insignificant.

For more information about our project risk management services and software, or if you just want to express your own views on the subject, please feel free to get in touch via our “Contact Us” page.

The words Risk and Uncertainty are often used interchangeably, and for good reason: The one cannot exist without the other. That does not, however, mean that they are the same thing. They are not.

Uncertainty drives risk, and risk exists where there is uncertainty. In spite of this fairly clear differentiation, I often hear people using the word “uncertainty” when they actually mean to say “risk”. The last time I heard it was when someone said to me, “Mike, we have an uncertainty in our project in that we may lose some of our key construction personnel. What can we do about it?”

What he really meant was, “We have a risk in our project in that it may be disrupted if we lose some of our key construction personnel”.

Although it was perfectly clear to me what was meant by his initial statement, using the word “uncertainty” in place of “risk” can still lead to confusion or misinterpretation at times. If you consider ISO 31000’s definition of risk, this is: “The effect of uncertainty on objectives”. Here it is clear that uncertainty is the driver of risk and is not risk itself. A dictionary definition of the word uncertainty is: “The quality or state of doubt”, but there are a number of equally suitable definitions for the word. One of my connections on LinkedIn (the same person who suggested I write this blog post, in fact) proposed that the definition of uncertainty is: “The range of possible success case outcomes (each with an associated probability of success)”. This is a perfectly acceptable definition, as it highlights the fact that uncertainty equates to a range of possible outcomes. This “uncertainty” or “range of possible outcomes” is intrinsically embedded in risk, as risk can also be described as, “A threat or opportunity resulting in an event which produces a range of possible outcomes”. (See our earlier blog post on the importance of accurately describing risk)

The difference between risk and uncertainty may be demonstrated through the picture of our Tentative Penguin above. This penguin is clearly displaying signs of uncertainty. He or She (how do you tell them apart?) is uncertain about taking another step up the icy slope. The reason he (let’s assume he’s a male for this discussion) is uncertain, is because his next step may result in him losing his grip, falling down and either hurting himself or sliding back down to the bottom of the slope. So here we can see that his “uncertainty” is founded in the range of possible outcomes of the risk, and is not the risk itself. After all, Mr Penguin is certain that his next step will be a risk for the very reason that the outcome of this step is uncertain! What I’m attempting to demonstrate here is that "uncertainty" can often be misinterpreted as "risk", where it is really only one of the ingredients that make up risk. One could say the penguin's uncertainty about the outcome of his next step is the risk, but here you need both the event of him taking a step, and uncertainty in the event outcome to make up the risk. An event without uncertainty in the outcome is not a risk, and uncertainty without an event produces no outcome, so again there is no risk.

For more information about our project risk management services and software, or if you just want to express your own views on the subject, please feel free to get in touch via our “Contact Us” page.

This is a generally well-known topic, but I do still get asked the question fairly regularly so, in this post, I’m going to provide a brief outline on the difference between Qualitative and Quantitative Risk Analysis.

In a nutshell, Quantitative Risk Analysis uses available relevant and verifiable data to produce a numerical value which is then used to predict the probability (and hence, acceptability) of a risk event outcome. Qualitative Risk Analysis, on the other hand, applies a subjective assessment of risk occurrence likelihood (probability) against the potential severity of the risk outcomes (impact) to determine the overall severity of a risk.

Risk management (in it’s very loosest form) can be traced back to the beginning of human origins, but it was only towards the end of the 19^th century, when high-rise buildings, complex railway infrastructures, large dams and canals started being built, that formalised project risk management techniques became more widespread in helping determine the outcome of a project. At that stage, however, risk management techniques were all still largely qualitative. Meaning the management of risk focussed only on identifying threats (or opportunities), subjectively establishing the likelihood of risk event occurrence and identifying the potential impacts of the risk. This 3-step process remains the foundation of qualitative risk analysis today, although we now have formalised methods and guide-lines to help us establish the severity of these risks, which would typically be done using a Probability/Impact ranking matrix.

The first known quantitative risk analysis method was developed by Henry Gantt in 1917 in the form of the Gantt Chart which, at the time, was used exclusively for schedule risk analysis. Gantt charts still form the basis of most schedule applications used today but, in terms of Quantitative Risk Analysis, the available methods have evolved and diversified greatly, providing us with a range of options specific to different risk types and their impacts. Quantitative Risk Analysis methods include, amongst others, Monte-Carlo Analysis, Layers of Protection Analysis (LOPA), Failure Mode and Effect Analysis (FMEA), Markov Analysis and Bayesian Analysis. Most of these methods will be meaningless to all but trained Risk Engineers and Managers, so let me try and describe Quantitative Risk Analysis by way of example.

In most operating facilities where there are inherent life threatening risks, such as oil & gas handling facilities, chemical processing plants, timber mills, mines etc. it has become mandatory practice to carry out a technical safety Quantitative Risk Analysis (QRA) to evaluate the risk to personnel working on the facility. The primary objectives of this type of QRA are to establish the Individual Risk per Annum (IRPA) and Potential for Loss of Life (PLL), and to then recommend measures to ensure the risks are kept As Low as Reasonably Practical (ALARP).

IRPA is calculated by multiplying the Location Specific Individual Risk (LSIR) by the proportion of time an individual spends in that location, and PLL is calculated by multiplying the IRPA by the number of personnel working within the location. LSIR is calculated as the sum of the frequency of each anticipated Major Accident Event (MAE) multiplied by the probability of fatality due to an MAE at that location. These calculations may be defined mathematically as follows:

LSIR = ∑ (F × P)

IRPA = LSIR x T

PLL = IRPA x N

The results of these calculations are then compared against a set of Risk Tolerability Criteria and, if they fall outside the acceptable range, mitigation measures need to be taken to reduce the results to fall within the acceptability criteria (or ALARP).

In our next post, we will consider another Quantitative Risk Analysis method, that being Monte-Carlo Simulation, and examine how this method is used to help predict the probability of outcome of certain events.

For more information about our project risk management services and software, or if you just want to express your own views on the subject, please feel free to get in touch via our “Contact Us” page.