Risk Management is a waste of scarce Organizational funds !

Posted on Aug 24, 2015

Image: How to take Risk out of your BusinessRisk Management – “The what”

A risk is defined as “an uncertainty that could have an adverse effect leading to loss, harm or damage”.

In practical project management terms, risks have the potential to increase the project cost and/or schedule, reduce quality and/or delivered scope, and even to derail the project and Customer satisfaction.

Obviously, not all risks are equal. Neither are all projects.

One of the key findings from the 2012 McKinsey study of large IT projects is that fully 17% percent go so bad that they can threaten the very existence of the company. These unpredictable high-impact projects are called “Black swans” in popular risk parlance.

Risk prioritization is the process step in Risk management where the Project team assesses the probability, impact, speed of onset, and vulnerability of each risk. In order to do this effectively, the Project organization would need to define acceptable thresholds of risk probability, impact, speed of onset, and vulnerability for the organization in general, and each project in particular.

The thresholds may be higher or lower depending on several factors such as:

  • The criticality of the Project outcomes to the organization, its brand, its profitability and longevity, its customers, and its employees.
  • The depth of insight that the Project team has into the Project problem and the proposed solution.
  • The Organization’s preparedness/ maturity to handle different scenarios/ outcomes.
  • The level of risk impact that the Organization is willing to accept (or is capable of accepting) in general for the overall organization as well as for the specific project in question – typically due to budgetary constraints, resource constraints, etc.

Risk management – “The why & why not”

Risks, by definition, may or may not occur. Risk mitigation activities would need to be planned well ahead of the Risks actually occurring. Further, certain Risk mitigation tasks may need to be executed ahead of time, in order for the mitigation to be effective. Hence Risk mitigation planning & execution activities entail expenditure of hard-fought project funds.

Further, in many projects where Risk Management is applied, it is applied by the Project manager with the best of intentions during project initiation & planning phases, but this interest and focus loses steam midway into the projects as they run into constraints of schedule, quality, scope or budget and the resulting pushback from project stakeholders.

Hence Risk management is frequently thought of as an unnecessary expense with low or no returns.

Risk management – “The how”

Only in mature organizations with a stable adoption of the Risk management process do we see projects strongly leveraging Risk management.

The major difference here is that Risk Management is perceived as an investment with potential for significant returns.

This evolution to a mature organization requires the following changes to be in place:

  1. Executive stakeholders have to recognize the importance of Risk management
  2. Executive stakeholders have to be prepared to allocate funding to build a culture of risk awareness
  3. Executive stakeholders have to be prepared to lead the Organizational risk culture implementation from the front, and
  4. An Organizational Risk awareness culture initiative has to be launched by means of Executive communications to the entire Organization.
  5. The Organization’s Software development processes & Project management processes have to be enhanced to incorporate actions relating to Risk management, and these new processes to be rolled out at the Organizational level. Rollout progress reports to be reviewed at Executive level.
  6. Risk management training to be rolled out to various categories of Stakeholders. Training progress reports to be reviewed at Executive level.
  7. Project Managers to be given authority to enforce Risk management directions. Project Manager escalations to Senior Management & Executives to be supported.
  8. Audits to be implemented, to ensure adoption of Risk management directions. Audit report summary to be reviewed at Executive level.
  9. Periodic (preferably semi-annual) Executive communications sharing progress of the initiative as well as the value / benefits realized from the initiative.

The following images depict a 10,000-foot perspective of the Organization and its Operational context, as well as the Organizational Risk culture initiative components.

Organization's activities


Organization's Risk awareness culture initiative


This article was first published in LinkedIn Pulse under the Title: “Building a culture of Risk awareness in Organizations”.

The most important preparatory document in a Cross-cultural Project team context

Posted on Jul 13, 2015


The Project Management Book of Knowledge (PMBOK) 5th Edition refers to several planning documents, which are all critical to project success in all varieties of project environments.

But in a cross-cultural Project team scenario, there is one preparatory document that can literally make or break a project but is not covered in the PMBOK – the Project Team Charter.

A Team Charter is a foundation for Project team operations. It documents the purpose of the team, how the team will work and behave, the expected outcomes, etc. It gives clarity and an operating framework or structure to the team, and effectively sets its boundaries.

Bruce Tuckman model for Group development

Model of Group development:

Bruce Tuckman’s Model of Group development has defined the 5 stages of a team lifecycle: Forming, Storming, Norming, Performing, and Adjourning.

  1. Within this framework, we can think of 2 different scenarios of Cross-cultural team formation:
    The creation of a brand new Distributed project team: The entry point into the Tuckman model is at the Forming stage.
  2. The evolution of an existing co-located Project team into a multi-location/ multi-cultural team: The entry point into the Tuckman model is at the Storming stage (with some added attributes of the Adjourning phase, such as Separation anxiety).

The development and adoption of a well thought-out Team charter would serve to reduce the duration of – or even eliminate – the Storming stage and help to move directly into the Norming & Performing stages.

Key considerations in Team Charter:

Key elements of Team charter

In the above scenarios of Cross-cultural team formation, creation of a Team Charter by engaging the full Project team would ensure that the team members are not just aware of the cross-cultural considerations, but are also clear about how these considerations impact the various team members and the overall project progress.

Group analysis of the various considerations by the entire Project team would force the team members to think and understand the implications of the considerations on the team & the project, and help to jointly develop the “Adaptation” strategy as documented in the HBR article “Managing Multi-cultural teams“.

In this picture, the various considerations have been classified into 4 high-level categories for ease of identification. Some of the elements may logically belong under more than one category, but have been placed under the best fit category.

Best practices for developing an effective Project Team charter:

  1. An Ishikawa/ Fishbone diagram can be used to identify all directly & indirectly impacted stakeholders in a project.
  2. Conducting a Team Charter Definition workshop, with all the key stakeholders actively participating, can really break the ice in team interactions and ensure optimal team productivity as well as team retention.
  3. Prior to conducting the Team Charter workshop, sharing the Team charter elements as well as other input materials with the Project team can help the team to attend the workshop with the right depth of early preparation, thus making the Workshop more effective.
  4. Also, conducting a Cultural awareness training (covering the cultural differences between various major cultural groups within the project team) ahead of the Team Charter workshop, will enable the Project team to best internalize and understand the points of view from different groups of stakeholders.
  5. The Project Sponsor should actively & visibly support the Team charter definition exercise – Implementing the Team charter is a bottom-up effort, but the application of any course corrections will require active support from the Project Sponsor and other Senior management/ Executive stakeholders.


Note: This article was first published in ProjectManagers.org.

Why on earth would I want to execute an OPM initiative ?

Posted on Jun 29, 2015

OPMWhat is OPM – as per PMI:

According to PMI’s Organizational Project Management Maturity Model (OPM3®) – Third Edition [1], “OPM is a strategy execution framework that utilizes portfolio, program, and project management as well as organizational-enabling practices to consistently and predictably deliver organizational strategy to produce better performance, better results, and a sustainable competitive advantage”.

The Model goes on to state – “OPM addresses the integration of the following:

  • Knowledge (of the portfolio, program, and project processes)
  • Organizational strategy (mission, vision, objectives, and goals)
  • People (having competent resources), and
  • Processes (the application of the stages of process improvement)”.


PM Solutions Benchmark study 2014What value does OPM provide to organizations?

In 2014, PM Solutions, Inc. surveyed [2] 293  high-level project management personnel from organizations of all sizes in various industries, including manufacturing, healthcare, technical, finance and government. The primary purpose of the study was to understand current project management practices as well as trends that will lead to improved project management success.

What sets high-performing organizations from the rest? They are much more mature in their project management practices than low performers (average level of maturity 3.4 vs. 2.5 on average and 1.7 for low performers). And they show substantially greater value in a variety of project management performance measures that matter most to executives, especially the percentage of cost savings per project (26% vs. 16% on average and 6% for low performers). Bottom line: More mature firms deliver more value.


But only Fortune 500 companies can afford an OPM adoption exercise !

Is OPM meant to be adopted only in large corporations with deep pockets?

Not true.

OPM adoption is a strategic investment that any Organization needs to make in order to: survive, become more competitive, and grow in today’s business world.

OPM recommends several best practices – Organizational enablers (OEs) in OPM3 parlance – that organizations of different sizes and at differing levels of organizational maturity can leverage, to improve their ability to deliver to their strategic goals. An organization can look inwards at its own vision, mission, strategic objectives and values, and decide which Organizational Enablers are most important to them for achieving the strategic objectives of the company. The Organization can also prioritize the OEs, with immediate attention being given to the OE that requires most urgent action.

OPM Value Proposition

So the more relevant question then is: Can an Organization afford not to execute an OPM initiative if it is to grow and stay competitive?

The attached image throws light on an everyman’s perspective of the dimensions of benefits that can be realized by implementing OPM.


Improve Visibility:

Well thought-out (simple, measurable, assignable, integrated) processes can help make required information available to impacted functions and stakeholders as needed by the work tasks being executed. This helps all impacted stakeholders to operate from the same context, and thus deliver work task outcomes that are in alignment with one another. Take an example of different parts of a Project team working to different versions or to differing understanding of the same Requirements document – This is the kind of eventuality that we have to avoid at all costs.


Improve Clarity:

Communication & education on Work task planning and execution processes across the organization leads to clarity into the “what”, the “why”, and the “how” of various work processes & procedures. All resources in an Organization should have clarity into what they are expected to deliver, by what schedule, what their activities are dependent upon, what activities are dependent upon their own assigned activities’ progress, and why they are doing what they have been asked to do. This clarity naturally drives improved & more predictable results – The entire organization owns their work and its results. It is to be noted that this benefit would also extend to external stakeholders such as Customers (who would have better insight into what is expected of them and what they can expect reasonably from the Company) as well as Third party Suppliers (who can be tracked with greater accuracy due to the improved understand between the Supplier & the Vendor).


Improve Control:

A natural outcome of improved visibility (of work task context) and improved clarity (into what/why/how of the work task) is improved Control, as Managers are able to better predict outcomes of work tasks, and finesse their delivery actions to achieve optimal results for the organization. This predictability of outcomes & schedule is absolutely critical for success in today’s fast-paced business environment – Your customers would not be satisfied with any less.


Improve Efficiency:

Well thought-out processes & procedures can help to drive out wastage as well as improve integration at various touchpoints, thus improving efficiency. For example, adoption of the Kanban method can help to reduce wait times for teams, and thus ensure that teams are optimally occupied without getting held up on other dependent work streams and tasks.


Improve Profitability:

Improved visibility, clarity, control, predictability, and efficiency lead to better cost savings as we are able to cut down on unplanned activities as well as on wastage, leading to improved profitability for the Delivery organization. We can redirect unused resources (in waiting state) to more productive directions for the company.


Enable Growth:

The achievement of benefit dimensions documented above can help us focus the Organization’s energies on organic growth, as the organization becomes more scaleable and with improved funding to invest in organic growth. Further, with the improved 360⁰ engagement of stakeholders (Customers, Delivery teams, Support functions, Third party Suppliers) as well as the delivery of more predictable outcomes, Customer satisfaction would improve, thus leading to business growth.



OPM offers the Organization an ability to analyze itself and its areas of improvements in a structured manner, and predictably drive improvements on the different Organizational Enablers. OPM assessment & adoption are exercises that every Organization should execute periodically, as it forms and refines its vision, mission and strategic objectives over the years.



[1]  © 2013 Project Management Institute, Inc. Organizational Project Management Maturity Model (OPM3 ©)- Third Edition.

[2] PM Solutions study, Oct 2014: Project Management Maturity & Value Benchmark 2014.



This article was first published in LinkedIn Pulse.

Top 3 enablers to effective Global Project Management

Posted on Jun 1, 2015

Global managementThe phenomenon of Globalization is a fact of life today.

Cross-border trade and immigration are increasing; Technology is connecting people seamlessly from around the world; Communications, transportation & travel solutions are both cheaper and faster; The use of common languages is lowering communication barriers; all leading to an increasingly interconnected and thus smaller world.

At the same time, new marketplaces are opening up. With the exception of the USA, the UK, the Eurozone & Japan, the world’s top 25 Rapid-growth markets are almost all “Developing countries”, with populations in the multi-millions and billions. Driven by their cultural divides, they carry very different values, beliefs, expectations, etc. On the flip side, unified by technology and social media, Customers are more discerning and more demanding about their expectations. Far more than ever before, Customer retention is the key to an Organization’s profitability & long-term survival. Service organizations mandatorily need to develop insights into cultural diversity in order to engage their multi-cultural customer bases.

On the other hand, getting the right resources with the right skills at the right cost to perform planned work is also becoming easier, with the advent of telecommuting and virtual teams. Organizations are no longer limited by hard constraints such as the reduced availability of cost-effective real estate & work spaces – The world is literally at your fingertips! But here too, cultural diversity plays a critical enabling as well as disabling role.

This is leading to a situation where Remote employee/ team management is now becoming a must-have skill for leaders and managers.

Managing remote customers is also becoming a business-as-usual requirement – The variety of mechanisms now available to connect to customers and assess customer engagement is enabling Service organizations to deliver their services more efficiently & cost-effectively than before – once again, driving up expectations on “standard” performance.

This Cheat sheet provides a 10,000-feet view of the 3 top enablers which a Global Manager must understand and leverage, in order to deliver his/ her Service delivery objectives more efficiently.

A key conclusion from this paper is: Leaders must not view the adoption of Global teams merely as a cost-takeout exercise. Without the right levels of preparedness and investments of funds, efforts and time, Global teams will not yield anticipated benefits. Indeed, inadequately planned implementations can end up poisoning the well for future initiatives by converting believers into skeptics.

Readers who require a more detailed picture than what is provided by this paper can go through the links provided in the References section at the end of the sheet. A big thanks to all the thinkers who have shared their insightful thoughts & inputs, which I have blended with my own thoughts to develop this model.

I welcome your thoughts & feedback on how this model can be improved.


Note: This article was first published on LinkedIn Pulse.

A new look at an old question – Is it necessary for PMs to have deep technical/ business skills ?

Posted on May 11, 2015

Ideal PM Skills mix

This perplexing question has been a repeated topic of discussion in many forums: Is it mandatory for IT Project Managers to have deep IT Technical skills and Business process/ Domain/ Industry skills in order to successfully execute a project ?

Other variations of the same question could be:

  • Can a Project Manager’s lack of in-depth Technical skills and/ or Business skills be attributed as the root cause for a project’s failure ?
  • Can a Project Manager move from one industry to another, and still be capable of performing effectively? Eg, Can an IT Project Manager move to a Manufacturing or Construction PM function, and perform a corresponding function in that industry ?

I propose that we turn this question around, and look at it from another perspective:

  • What are the project context factors that force the need for Project managers to have deep Business/ Industry skills and Technical / Integration skills ?
  • Would it be possible for the Project Organization to identify and address the impact of these project context factors & thus mitigate the risk of the Project Manager’s shortfalls in Technical & Business skill areas ?

The attached figure attempts to capture the various factors which have impacts on this question:

Factors driving PM Skill needs

  1. Project size: If a project is small, and does not have adequate funding to include in the Project team those Subject matter experts (SMEs) who can effectively address project questions relating to the Project’s Industry context, Business objectives & processes, and Technical platform including integration aspects, then it may be necessary for the Project Manager to perform such functions. Conversely, on a large project, it may be difficult for the Project Manager to have deep insight into all aspects of the Technical platforms & Business domains impacted by the project, and may need specific portions of the project to be delegated.
    Examples for both scenarios:
    (i) An Application maintenance project that involves enhancement of a specific system or application could be project-managed by the Application Manager who may have requisite levels of technical & business knowledge to lead the project from these perspectives. However, as Project size & complexity increases, it becomes less possible for the Project Manager to cover all Technical & Business skill areas on his/ her own.
    (ii) A complex Transformation project may involve integration of multiple COTS (Commercial off-the-shelf) products as well as implementation/ enhancement of multiple business process flows. One Project Manager would not be able to have insight into & keep track of all of these; So specific areas or parts of the project may be delegated to other Project Managers, and PM who owns the entire project may be a Senior Project Manager or Program Manager. In this scenario, the Senior Project Manager is not likely to have all the Technical & Business skills, and may only have insight into a subset. But that would not take away his/her responsibility to own & manage the entire solution.
  2. Business criticality & visibility of the project: This is more of a political issue rather than a “real” factor, but carries significant impact. A Business-critical project may be under close scrutiny by Company Executives, and the Project Manager may have to face a barrage of questioning relating to project progress, expectation mismatches, issues blocking project progress, specific scope elements of interest to special interest groups, etc. If the Project Manager is not sufficiently insightful about all aspects of the project & is unable to respond to the queries in an effective manner (without forever saying “Let me come back to you on this”), then the tenure of the project manager on that project is not likely to be very long.
  3. Project urgency / Schedule flexibility: If the Project schedule is tight & does not permit the Project Manager to have a learning curve, then it is necessary to have a project manager in place who has had prior experience within the space (having executed similar projects in terms of business objectives, technical platform, etc).
  4. Availability of Subject Matter Experts (SMEs): If a Project team includes SMEs in the areas of Technical platform, Development and Test tools, Systems integration, Business analysis, Business process, Industry best practices, etc, and if these SMEs are able to effectively support the Project manager in these skill areas, then the PM can delegate certain responsibilities to the SMEs and take their support where the responsibilities cannot be delegated. For example, if a 3rd Party Vendor is contracted to perform a specific function where the PM does not have adequate skills, then the corresponding SME(s) can perform the function of delivery reviews & status reviews with oversight by the PM.
  5. Executives’ engagement and Expectation management: In any large project, it is quite possible that there are Executive stakeholders with conflicting expectations and priorities. The Project Manager, in this scenario, will need to work with SMEs from the respective teams to arrive at a negotiated agreement on project objectives and implementation approach, and then propose the negotiated agreement to the impacted Executives. On the other hand, if the Project Sponsor and/ or impacted Executives are not effectively engaged on the project, then key decisions may be left hanging and key help needed items may not progress, impeding project progress. In either scenario, the Project Manager would need to be armed with the necessary depth of details & understanding so as to appropriately communicate with and effectively engage the Executive stakeholders.
  6. Business Requirements prioritization: In case of projects where different impacted functions have conflicting or tangential project requirements, it would be necessary for the Project Manager to step up and negotiate an agreement on how the various systems and functions would operate in order to achieve the project’s ultimate objectives. Further, in large projects, it may be necessary to phase out the deployment of various project objectives into multiple stages or deployment cycles so as to reduce risk as well as to give an opportunity for various dependent stakeholders to catch up with the project execution. In such scenarios, it is necessary that project objectives be prioritized so that the various impacted stakeholders have clarity on what is a must-have vs a good-to-have, and what’s a must-have-right-now vs what’s a must-have-but-a-while-later. The Project Manager should have necessary insights to drive this negotiation, or have adequate support from Subject Matter Experts (SMEs) to help the PM drive the negotiation.
  7. Solution Complexity: In case of a complex solution that includes many moving & dependent parts, the PM would need to necessarily have some level of insight into the dependencies, so as to quickly assess impacts in case one or more of the moving parts is held up. Further, in the case of a First-of-a-kind or FOAK solution (eg: projects integrating new COTS or Commercial off-the-shelf products for the first time), the PM would need to have adequate depth of understanding of the FOAK solution, its components, the dependencies, and the risks involved, so that he/she can quickly assess impacts in case of any changes, defects, or component delays.
  8. Vendor Management: If the project team includes vendor(s) who are performing functions which lie on the project’s Critical path, then the Vendors and their work would need to be closely managed, so as to preempt any project slippages. In order for this to happen, the PM would need to have adequate depth of insight into the Vendor’s project plan, interim work artifacts, solution dependencies etc into the overall project solution.
  9. Workplace culture and politics: In a “blaming” organization, scapegoats are quickly (and possibly unfairly) identified for failures. In such situations, there is a natural propensity to play safe. Creativity, productive risk-taking behavior and innovation would drop, and wariness would be the norm. In such an environment, PMs who are not adequately armed with all requisite skills and insight would be a natural scapegoat for any delays or issues, even if trivial.

By assessing their projects against the above factors, and by assessing the ability of the Organization to mitigate any identified risks, Project Sponsors would be able to determine the best direction to take with respect to PM allocation – if the Project needs a Technical/ Business-skilled PM, or if a strong PM without in-depth Technical & Business skills would be able to lead the project to successful completion.

Criticality of Stakeholder Management in the context of Large IT Project Management

Posted on Apr 27, 2015

Stakeholder Management

The McKinsey – Oxford University research [1] into 5400+ IT projects in June 2012 – Delivering large-scale IT projects on time, on budget, and on value – makes for very interesting reading. A key finding which came out of this research is that large IT projects (Initial budget> $15M US) on average ran 45% over budget, 7% over schedule, and delivered 56% less value than planned. Even more interestingly, fully 17% of large projects (called Black Swans) go so bad as to threaten the very existence of the company.

From their research, McKinsey also identified 4 broad dimensions for improving control of large IT projects:

  • Focusing on managing strategy and stakeholders instead of exclusively concentrating on budget and scheduling
  • Mastering technology and project content by securing critical internal and external talent
  • Building effective teams by aligning their incentives with the overall goals of projects
  • Excelling at core project-management practices, such as short delivery cycles and rigorous quality checks


McKinsey Value Assurance assessment elements


On analyzing the Project success factors identified by McKinsey, it becomes apparent that effective Stakeholder Management is a critical enabler to the success of large IT projects:

  • Clear Project objectives: Improvement of this Success factor requires strong User involvement, which would in turn be enabled by effective Stakeholder management.
  • Well-defined business case: Improvement of this Success factor requires Clarity into Project objectives & strong User involvement, which would in turn be enabled by effective Stakeholder management.
  • Alignment of major stakeholders: This success factor can be achieved by effective Stakeholder management.
  • Minimized, stable project scope: Improving this Success factor requires clarity of objectives, strong User involvement, and a Qualified & motivated project team. These would in turn be enabled by effective Stakeholder management.
  • Robust vendor contracts with clear responsibilities: Improvement of this Success factor requires strong Procurement processes, clarity into Project Objectives, clarity into the skills & skill levels of the internal teams, Project management expertise, as well as an effective Project Management methodology. The first 4 factors would be in turn be enabled by effective Stakeholder management, while the last would necessitate a mature Organizational Project management methodology.
  • Executive support: This success factor can be achieved by effective Stakeholder management.
  • Standardized, proven Software technology: Improvement of this Success factor requires a qualified Project team that is able to understand the project objectives and recommend the right, proven Software technology to achieve the project objectives. This, in turn, would be enabled by Executive support, which can further be enabled by effective Stakeholder management.
  • User involvement to shape solution: Improvement of this success factor can be achieved by effective Stakeholder management.
  • Experienced Project manager: Improvement of this success factor can be achieved by Executive support, which can further be enabled by effective Stakeholder management.
  • Qualified and motivated Project team: Improvement of this success factor can be achieved by Executive support, which can further be enabled by effective Stakeholder management.
  • Sustainable mix of internal and external resources: Improvement of this success factor can be achieved by Executive support, which can further be enabled by effective Stakeholder management.
  • Reliable estimates and plans, appropriate transparency about project status: Improvement of this success factor can be achieved by means of a mature Organizational Project Management methodology.
  • Proven methodologies and tools: Improvement of this success factor can be achieved by having in place a qualified Project team that can recommend and effectively adopt these methodologies and tools in the project.

The conclusion that can be drawn is that adopting an effective Stakeholder management strategy can yield substantial benefits on most of the McKinsey-recommended Project success factors.

Recommendations on improvement of Stakeholder management can be found in the article “4 Steps to effective Stakeholder management” on the pmExcell website. I have on focused the Stakeholder analysis activity to greater depth here, since this step may be the make-or-break activity that really makes a difference to a project’s success or failure.


[1] McKinsey and Oxford University study – Delivering large scale IT projects on time, on budget, and on value, 2012.

Driving up Stakeholder engagement during Risk Identification and Assessment

Posted on Apr 14, 2015

Risk management is frequently added an afterthought in the Project planning process. It is also a process that is adopted by Project Managers with the best of intentions at the beginning of a project – However, this adoption frequently loses steam mid-way as the schedule/ quality/ scope/ budget pressures on the Project Manager increase, and stakeholder support to risk management drops. Only in mature organizations do we see Risk management being actively pursued with the same vigor & persistence throughout the Project lifecycle as with other Project aspects such as schedule, cost, quality, etc.

One major reason why this happens is: Many organizations do not fully realize the benefits to be accrued from implementing an effective risk management program, and the repercussions of not having one. Further, Project Managers may not be able to appropriately qualify & demonstrate this value and implications to all stakeholders, specially at Executive levels.

This paper proposes a set of process steps & templates to systematically improve stakeholder engagement on risk management at different levels of the organization, and thus improve the effectiveness of Risk Identification, Prioritization, Communication and Mitigation within applicable projects.

It is to be noted that many of the steps in this paper are already defined and in use elsewhere; This paper merely brings these steps together. It also attempts to bridge certain gaps and address certain areas of improvement, specifically relating to the visual representation of risks categorization & prioritization.

Problem statement:

Chaos Manifesto, 2013 [1] has named Executive support, User involvement, and Project Management expertise as 3 of the Top 10 drivers for Project success. The McKinsey & Oxford University study 2012 [2] concluded that the foremost approach to improve project performance is to “focus on managing stakeholders and strategy instead of concentrating on budgeting and scheduling”.  Yet, other than Quality Management, Risk Management is likely the most misused and underutilized knowledge area of A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fourth edition (Project Management Institute [PMI],2008).

Risk management implementations are frequently less than effective, most typically due to:

  • Lack of engagement of impacted stakeholders during Risk identification
  • Lack of engagement and support from Executive stakeholders for “Help needed” activities during Risk Mitigation phase

The Root causes of both the above factors lie in ineffective Project Management, and is compounded by the lack of Organizational Project management maturity. The Politics & Culture of the Organization also play a major part, by influencing levels of Executive support to projects and initiatives.


This article proposes a series of steps and templates that can be adopted to drive improvements in Risk acceptance by impacted stakeholder teams, while also driving improvements in establishing visibility of major risks & help needed at the requisite Senior Management and/or Executive levels of the Organization.


1. Structured Risk identification:

It is proposed that we use VIRT (Visual Ishikawa Risk Technique [3], also called Cause and Effect diagram or Fishbone diagram) or other similar approaches, combined with group interactions (such as Brainstorming, Facilitated Workshops, Delphi technique, etc) to identify risks as well as to engage the entire Project team on the identified risks.

2. Qualify & categorize risks

Risk assessment can be performed using a traditional Risk matrix, but the quality of assessment and prioritization can be significantly improved by enhancing the risk attributes used for risk quantification and categorization.

It is proposed that for risk assessment, we adopt the COSO ERM Integrated Framework guidance for Risk assessments as documented in “Risk Management in Practice” [5].

3. Generate a Visual representation of risks:

It is proposed that we use the Risk Heat map to generate a visual representation of identified risks.

The Risk Heat map charts risks in the traditional manner with Likelihood & Consequence on X- and Y-axis of a matrix, and then enhances the visual depiction by including Vulnerability and Speed of Onset of the risks in the chart.

4. Identify risk conflicts/ escalations:

It is proposed that we use Risk Interaction matrix to identify and document Risk conflicts and escalations.

5. Generate a Visual representation of Risk Interaction:

It is proposed that we use the Risk Interaction map to generate a visual representation of prioritized risks.

6. Submit to Project Governance Forum:

It is proposed that we establish formal, periodic Project Governance channels to drive up visibility into the requisite Senior Management or Executive layers of the Organization. It is further proposed that we use the Risk Heat map & Risk Interaction map in conjunction to improve Executive/ Senior Management visibility and engagement on high-priority risks that need their attention & action.


Additional Information on Templates used:

For additional details on the Risk Matrix and Risk Map, and to access the Templates, please read the article “Enhanced Risk Matrix and Risk Heat Map” in the Assets area of the pmExcell website.

For additional details on the Risk Interaction Matrix and Risk Interaction Map, and to access the Templates, please read the article “Enhanced Risk Interaction Matrix and Risk Interaction Map” in the Assets area of the pmExcell website.



To be successful, Risk assessment requires adequate resources as well as Executive commitment. Risk Assessment cannot survive in isolation, without being supported by and being dynamically connected to an Organization-level Process Framework that includes processes such as Project Governance, Portfolio management, Financial planning, Contingency reserve management, etc. Risk acceptance & visibility are critical to project success, specially as the complexity of the project increases.


Additional Notes:

VIRT is a mechanism that can be used to progressively elaborate the causes of risks, given a specific effect.

An example of implementation of a Fishbone diagram implementation is provided in the white paper “Application of Fishbone diagram to determine the risk of an event with multiple causes” [4] (Link: http://mrp.ase.ro/no21/f1.pdf).

Information on approaches for Group interactions can be located here:



[1] Chaos Manifesto, Standish Group, 2013.

[2] McKinsey and Oxford University study – Delivering large scale IT projects on time, on budget, and on value, 2012.

[3] Visual Ishikawa Risk Technique – An Approach to Risk Management, Jen R, PMI Virtual Library.

[4] Application of Fishbone diagram to determine the risk of an event with multiple causes, Ilie G. and. Ciocoiu C.N.

[5] Risk Management in Practice, Dr. Curtis, P. and Carey, M, Deloitte & Touche LLP, Research commissioned by COSO (Committee of Sponsoring Organizations of the Treadway Commission)