Dealing with black/gray swans

A black swan  in a complex system, as popularized by Nassim Taleb  is a metaphor for a large impact, rare event that comes as a complete surprise to all stakeholders. A gray scan is a metaphor for an event with large impact  with very low probability, with the result that most stake holders ignore.  Usual risk management practices deal with known knowns where the adverse event occurrence as well as impact are both predictable.

Credit:Arjuna based on Marek Szczepanek(Wikimedia)

As the world is more digitized and interconnected and is dependent on large complex information systems,  stakeholders are increasingly facing  black/gray swans.  The impact increases as most of these are unique, connected and closed systems like mobile phone network, power grid and applications based on Internet.  The glitches and shutdowns are regularly chronicled in IEEE Spectrum risk factor blog.

In an excellent paper "Management of Hidden risks", IEEE Computer, January 2013, (paywall)  the author Kjell Jorgen Hole recommends few suggestions to deal with gray swans based on the experiences from the outages in Norwegian Mobile phones, Electronic voting systems, and bank payment authorization systems based on public key infrastructure. The suggestions include  identifying the dependencies between systems and ensuring that the system can continue to run for a minimum period by using back up system (for Mobile networks), providing an alternative mechanism (like paper based ballot for e-ballot) and alternative authentication mechanisms and confirmation messages (for banks). It is useful for project/engineering managers to learn from these and  plan for  dealing with gray swans.

Oppportunity Management

During my recent talk on Risk Management Best practices, I focused on applying standard risk model, which requires identifying the event  and its impact explicitly along  with their respective drivers(causes). Separate identification of drivers enables  preparation of prevention   and contingency plans. A participant asked me a question of how to manage opportunities,  events which  reduce the time, budget for a baselined project. As per PMBOK,  opportunities are managed the same way as risks. A detailed risk and opportunity management process applicable for a city council is a good read to understand the application of this concept. In IT/engineering projects, Opportunity Management  is not so common. In this blog post, I explore the Opportunity Management and share few thoughts that I hope are practical and useful in practice.

Usually projects are taken up to address an opportunity such as addressing a underserved customer need, acquiring new skills, establishing a platform/IP that can be leveraged for a long time. This means that entire project is actually an opportunity management at the level of organization's portfolio.

Estimates for complex projects involve great deal of uncertainty. These are generally optimistic given the excitement around new project and general human optimism, despite the use of robust processes. Once the project is approved, the focus is on delivering  the project as per expectations while managing  threats.  Given a good system engineering approach, work is planned and executed to deliver as per expectations. Multiple options with respect to schedule/cost are explored as part of Project Management before baselining. This process  implicitly manages the opportunities to reduce the schedule/budget.

Due to change in customer scope or technology advances,  it is possible that certain options which were not explored during the project proposal/planning phase may become desirable for long duration projects.  At the same time, such options will not be without their share of risks. As an example consider that an enterprise mobile  application was planned initially for  one category of mobile Operating system, During the course of development,  the push for Bring Your Own Device (BYOD) made the need for supporting multiple mobiles became a pressing need. Then the opportunity of utilizing  a mobile OS neutral platform, which allows seamless targeting of mobile app to  other mobile operating systems become attractive.  In such a  case, it is advisable to pursue such  opportunities if the cost/time benefit after considering the risks associated with it  is beneficial.  If not, then it  would be more useful is to route such ideas behind opportunities through innovation pipeline of the organisation/group.    Once the idea passes through the innovation pipeline, the technology developed could be utilised in  future projects.

So in summary, my view is that opportunity management is implicitly practiced at the project level. It is more practical do it explicitly at the portfolio/organisation level. Share your perspective?
 

Benefits of Risk Breakdown Structure for Portfolio management

One new concept in PMBOK 5th edition is called Risk Breakdown Structure(RBS). This is a powerful concept to improve the risk management practice in the organization. Let's explore this in more detail in this post.

Graphics Credit:Andreas Plank 

During the postmortem or retrospective, lessons learnt from the project are captured including the experience with the risks. Usually this document in the form of a word document or Excel register is stored in the repository. If an organization has an efficient search engine for the repository, these documents may become useful for future projects. Though the tacit knowledge of the team is captured in the document, it is still not effectively used, because it is not in structured form.

The creation of Work Breakdown Structure(WBS) is critical for Scope definition and subsequent project tasks. As WBS is a hierarchical depiction of deliverables at various levels of granularity, it is useful for planning and reporting to various stakeholders. RBS arose from the need to organize the huge list of risks identified in a project. As its name indicates, it is also hierarchical organization of risks in various categories. If we look at a software project,(As per Dorofee A.J et.a's 1996 book "Continuous Risk Management Guidebook" quoted in Dr. David Hillson's article "User Risk Breakdown Structure to understand your risks", 2002) the sample organization at the first level could be product engineering, Development environment, project constraints. At the second level product engineering could be broken down to life cycle phases, Development environment could be broken down to development process, management process, work environment. Similarly the project constraints could be split into team, contract, and interfacing stakeholders.

RBS can be used instead of traditional risk check list for risk identification. Or after the risks are identified by other methods, these can be organized into this structure. Once this is done, insights such as dominant categories of risks can be gained. Additional risk identification sessions can be undertaken based on RBS to make the exercise comprehensive. Similarly the hierarchical nature of categories allows appropriate focus at the various organization levels. If all projects follow this, portfolio risk management becomes easier, as the risks can be aggregated in relevant organization wide categories and handled. At the closing of the project, populating the risks lessons learnt as per the RBS in a database makes this knowledge much more useful for future projects.

Did you use RBS? Are there any better methods? Share your thoughts.

Effective risk Management-Actual Risk impact model

Several tools  are used at the project level to identify, analyze and accept/mitigate risks. The  risks that could impact a program/portfolio are picked from the project list based on potential loss exceeding a certain threshold and few risks that could not be handled at the project level and appropriate corrective actions are identified and implemented.   This kind of approach  is primarily focused on dealing with the project risk and does not  highlight  the potential impacts at the organization  as well as leverage the organization resources for risk management effectively. 2010 Deep water Horizon accident  in Gulf of Mexico is one example of how a project risk can cause huge loss to the enterprise, if not handled effectively.

A model of risk impact  proposed by  Prof. Hans Thamhain(Managing risk in  Complex Projects, Hans Thamhain, Project Management Journal April 2013 page 20-35(may require membership of PMI)) helps us get better insight into the nature of risk management at the enterprise level based on major field study  of 35 major product developments in over 17 high tech organizations.  The model is based on a  key observation that successful  risk management is only achieved when project environment is conducive to effective cross functional communication and collaboration among all stake holders. This model  categorizes risks into four groups. Cat-1 risks  are those that  do not impact project performance yet. Cat-II risks impact project tasks and subsystems. Cat-III impacts project performance, Cat-IV impacts project and enterprise performance. The key idea is that a risk can move from Cat-1 and Cat-IV  during its life, if it is not managed well.  A nice example for this is the Toyota's accidental acceleration problem which led to the recall of several vehicles thus impacting the enterprise.

This model helps in understanding the  role of work process, organization environment and people in managing the risks. Some of the  learnings for effective risk management in complex projects from this research include  a)Unchecked contingencies tend to cascade and penetrate wider project areas  b) Cross functional collaboration is an effective catalyst for collectively dealing with  threat to  project environment  c)Senior Management has a critical role in creating a conducive organizational environment d)People are main sources for uncertainty as well as  resources for reducing risk.