Managing Risks and Stakeholders

Stakeholders are the major sources of risks.

In order to frame this provocative statement, some citations are useful:
Stakeholders:“Individuals and organizations that are actively involved in the project, or whose interests may be positively or negatively affected as a result of project execution or project completion. They may also exert influence over the project and its results.” [1]
Risk is defined as ‘an uncertain event or set of events which, should it occur, will have an effect on the achievement of objectives’. [2]
Risks have three components:

1. A future root cause (yet to happen), which, if eliminated or corrected, would prevent  a potential consequence from occurring,
2. A probability (or likelihood) assessed at the present time of that future root cause occurring and,
3. The consequence (or effect) of that future occurrence. [3]

This is a compelling reason for thinking the “Risk Management” as an activity developed in partnership with stakeholders. Here below are listed some common misconcepts and attidudes that could undermine the correct Risk Management approach:

1. Flexibility (either in requirements or quality) can reduce the risks.
2. Avoiding strict criteria for measuring success, could increase the margin for manouvring each outcome for improving the output quality
3. Change Management, a key tenet of Risk Management, could be intended as a limitation to the commercial freedom from (Sales and Marketing people) [4].
4. Informal approach (based on mutual trust) would avoid, quicker solving most of the critical situations (i.e. among friends it is easier to find an agreement).
5. Risk management budget could frighten customers and senior management.
6. Assuming that everybody is familiar both with the chosen technology and methodology.
7. Not linking the properties of quality to the customers’ satisfaction.

Some (possible) answers

1. The definition of risk assumes the existence of a baseline. Any variation can be measured only from an established reference. By the way, it offers a solid ground for building the foundations.
2. The “Iron Triangle” values shall be integrated (it is difficult to substitute them) with customers’ values (e.g. quality)
3. Change Management is an established procedure for evaluating the feasibility and impact of any variation
   1. The control of change means the assessment of the impact of potential changes, their importance, their cost and a judgmental decision by management on whether to include them or not. Any approved changes must be reflected in any necessary corresponding change to schedule and budget.[5]
   2. It is not only a set of skills (mostly based on negotiation and a good versioning system). It shall be a structured process involving the stakeholders:
      1. Customer / Product Managers presenting a Business Case for each modification required
      2. Developers / testers who can approve the feasibility (e.g. security, maintenance) and then estimations (costs and time)
      3. Sponsor (Project Manager) who chairs the board
4. Important projects involve big organization (and put at stake a lot of money). It is extremely difficult to base all agreements solely on a “gentlemen’ agreement”. Yes, mutual trust is an essential ingredient. However, left alone is not sufficient.
5. The budget (raw figures) shall be shipped with the criteria used for producing it. These criteria, presented like concepts, can be form a good basis for a strong negotiation. The common pitfall is to surrender on figures without changing the premises.
6. The deepest root of any risk is an unchecked assumption.
7. The definition of “Quality” has to be translated into operational topics, like:
   1. Resource management. How much in percentage developers will be involved in these activities (i.e. Unit Test and Peer Review)?
   2. Which are the areas that can be considered worth enough for being tested?
   3. Are the meaningful and correct (updated) data available for testing the key features?
   4. How much time of “final users” is allocated for (functional) testing?

Conclusions

Risk Management is an essential part of the PM and it is the activity that mostly involves stakeholders. This statement should be strong enough for dedicating it the necessary resources and training.

More Readings and references

1. PMBook Guide 2000 Edition
2. M_o_R Guide 2007
3. Risk Management Guide for DOD Acquisition – Sixth edition
4. Software Project and Process Measurement – Dr. Christof Ebert – Vector Consulting Services
5. Prince 2 manual (2005 Edition)

http://sourcesofinsight.com/2009/08/04/clarify-meaningful-results/

Image courtesy of: http://www.touregypt.net/featurestories/treaty.htm