Project Risk Management – Tools and Techniques

Every project, regardless of scope or complexity, is going to have some inherent risks. The type, number and severity of the risks will vary depending on a variety of factors, such as the project’s overall size, its related constituent pieces, the number of individuals on the project, and so forth.

But how does the project manager effectively catalog these risks? How are they adequately itemized and made part of the overall project management plan?

Any sort of risk assessment, regardless of the situation, is always a combination of both art and science, coupled with the individual’s own personal experience and knowledge. Because risks are, in and of themselves, intangibles, cataloging them can be somewhat daunting.

The PMBOK (Project Management Body of Knowledge) has an entire chapter dedicated to the concept of risk management. In some cases, seasoned professionals are actually brought in to provide their consulting expertise to make sure that all project risks are effectively itemized. But in most cases, it falls onto the shoulders of the project manager to be able to make that assessment. With that being said, how should the project manager proceed?

If one follows the PMBOK’s suggestions, it is important to create a task list. The PMBOK suggests the following tasks to be performed in sequence:

  1. Define the Risk Management Process (And make this part of the overall project plan)
  2. Identify Risks
  3. Perform a Quantitative Risk Assessment
  4. Perform a Qualitative Risk Assessment
  5. Create a Risk Response Plan
  6. Monitor Risks during the life-cycle of the Project

As some might indicate, the most difficult step in the process itself is to identify the risks themselves. There are some rules of thumb that one can follow when it comes to assessing the risks themselves. A step approach could be something like so:

  • Examine the plan and scope of the project; identify short-term tasks and assess the risk of each one individually
  • Examine the project as a whole; if there are dependencies (internal and external), assess the risk of those dependencies and catalog them
  • Determine the risk of the project not succeeding; what are the financial risks that one must be aware of
  • Assess the budget of the project (if any); determine areas that may induce risk pertaining to budgeting (i.e. cost of contractors, cost of tangibles, etc)
  • Determine any external risk factors, such as competitors or potential changes in market sentiment in regards to the project and its deliverables

Once the risks themselves have been itemized, there are two different ways of assessing the risks: quantitative and qualitative risk analysis. Those are defined as follows:

Qualitative Risk Analysis – This is the more subjective of the two. It relies very much on the experience of the project manager in being able to effectively gauge the risks themselves. A good rule of thumb when performing this type of analysis is to ask specific hypothetical ‘what if’ type questions. A few examples might be:

  • What if engineer ‘A’ leaves the project or is reassigned?
  • Have the requirements been properly itemized? And what if they haven’t?
  • What if the budget is adjusted half-way through the project’s implementation?
  • What if the learning curve for new technology is steeper than anticipated?
  • What if a dependent project runs into trouble? How will that affect the primary project?

Quantitative Risk Analysis – This uses more tangible or ‘hard’ assessment types, such as percentages, probabilities and numbers to demonstrate some of the risks that could cause project problems. In many cases, having this type of assessment available is very important to certain senior management types that require more in the form of numerical values as opposed to more subjective measures. Things like schedule ranges, cost budget ranges, and probability analysis (best or worst case scenario calculations) would fall into this scope.

When it comes to risks, experience of the project manager is the most valuable asset. So if you are a newbie, it might be a good idea to discuss risk analysis with more seasoned and experience project manager’s to gain their insight, especially if they have more working knowledge of a particular area. Also, when you become more familiar with risk analysis, creating a checklist that you can reference for future projects is a very good reusable resource that a project manager can leverage. Combining your list with those of other project managers will also allow you to have a more complete assessment of all the potential risks and risk types that you need to be cognizant of when monitoring your project.

The following graphic is a good frame of reference when it comes to the risk analysis cycle:

It demonstrates the ‘cyclical’ aspect of the overall risk management process. So ensure that you utilize it for reference during the project life-cycle to ensure you are effectively monitoring the project risks.


Project Management in the Global Village

The world, as we know it, has changed dramatically in the past thirty years. The technological revolution, modernization of various countries, the internet and social networking have expanded the reach of both companies and individuals alike.

Nowadays, the notion of remote offices and remote workers has become a staple aspect of many corporations internal configurations. Whether the choice to accommodate remote access is one of cost or simple logistics, the fact remains that it is now a common theme across all types of organizations. Invariably, anyone working within the technology spaces, especially those in the software sector, will often be part of groups that span both domestic and global geographies.

With that being said, what exactly does this do in respect to managing large, disparate groups that can cross both geographic and cultural boundaries? How does the modern-day project/program manager handle situations where their resource pool may be either co-located for certain individuals while also being dispersed for others? How does a good project/program manager ensure that he/she is still able to stay on top of all aspects of their particular area and ensure that harmony and collaboration exists for all members of the team?

The first question is ask is the following: does any of this make the current notion of a project/program manager obsolete?

The answer, as some might already have guessed, is a resounding ‘NO‘.

If anything, the need for an effective project/program manager is required now more than ever, considering the disparate nature of project development. By their very nature, project/program managers are meant to be the proverbial herders of cats. The individuals that maintain the communication channels and ensure all individuals involved in any project are kept up to date and well informed. Being that large geographic boundaries need to be crossed in the modern world, this is not merely a ‘nice-to-have’ concept, it is an absolute essential.

So what tools and techniques can the staple project/program manager utilize in order to ensure that the communication channels are being handled effectively? Fortunately, with the modern world, come modern technologies that can be leveraged:

  • Blogs, wikis, social networks and shared workspaces – Group environments existing online (either internally or externally) are now a common meme for most in the industry. By leveraging some of these environments, individuals that are part of a common project can post status updates, share documents and engage in dialog, all within cyberspace. The added benefit is that one can always reference these conversations afterwards since they will be always available and show a running history of the dialog.
  • Email – Since its advent, email has become THE defacto communication mechanism within the industry. By leveraging common email lists or controlled email trees, the project/program manager can be in the thick of the communications. Note that email can become cumbersome in its absolute sense due to over usage in a company. So utilizing filters and common mailbox spaces will help ensure that important exchanges are not buried amidst the regular ‘noise’.
  • Online Meeting Software – Several different versions of this type of software exist: WebEx, LiveMeeting or GotoMeeting. All essentially function in a similar way: it allows disparately located individual to be able to see the same content online in real-time. A wonderful added benefit of many of these software offerings is that many also support WebCam content display. So individuals on a common conference can actually see each other, which adds a more personal level of interaction during the meeting.
  • Instant Messengers – These can be in the form of regular messenger mechanisms like Yahoo Instant Messenger or MSN Messenger. Or they can be evolved into more elaborate systems like twitter communications or chatter messages and posts on things like FaceBook or Salesforce.

One thing to note: it is sometimes tempting to ‘overload’ the communication stream by attempting to leverage too many of these tools at the same time. This can be detrimental to the overall project since it will lead to confusion and information overload. It’s best to investigate which tools and techniques fit the situation overall and make it a focal effort to utilize just those tools. This will ensure that individuals on the project are fully cognizant of exactly which communication streams to monitor and how to effectively engage in dialog with their peers.