Risk Management

Posted on July 12, 2013 by ThePMJournal

-What is this?

-It’s a new Risk, Andrew.

-We have only one month until deadline and do you tell me there is a new Risk?

-Andrew, a risk does not mean it is already happened. In addition, I cannot foresee all the risks of a project from the beginning. Some risks appear or disappear depending on the evolution of the project. What do you want me to do? To tell you that the project has no risks?

-We need to talk. There are a lot of grumpy people complaining you don’t have the project under control.

In many companies, management of risk is a taboo subject. When people hear about “risks”, behave like they hear the devil; they panic and try to blame others:

-What means we have risks? And we know just now? And the Project Manager what the hell is doing?

These discussions take place because few know what is a risk, few know how can a risk be managed and most of the people believe the risk management responsibility belongs totally to Project Manager. All expect from PM to be some kind of super-god, who knows in advance what will happen with the project, with the humanity, that he can prevent all the bad things in this world, that can even fight with the bad dragons and if is necessary, he will solve impossible so all the key stakeholders can sleep quietly at night. The Project Manager is stronger than Chuck Norris…

I was working as a Program Manager at one of the most ambitious products suite from software security industry. When I received the program, the projects charters was already approved (at least so the Sponsor said). Later, I realized what meant Sponsor by “a project charter“: an email with few notes with so called “objectives” (in a form of utopian stories), the deadline in four months from now on, limited resources and in the end “Good luck!”. I put my hands on my head. I knew from the beginning the projects were under-estimated, the resources will be over allocated, the deadline was unrealistic and imposed without consulting the technical team, and above all the risks were ignored. Probable they imagined when I will took the project (which was in fact a program of inter-related projects), I will manage all the risks and, by magic, save also the company honour. Why the company honour? Because, the main cash flow for the next year depend on this project; also the company quotation on the market depends on project success (by the way, the company was supposed to be sold urgently with a best price to some new investors…), in other words what I had to do was not only “a mission impossible” project, but also optimizing operation costs, implementing a PMO and other stuff like this which could make even Chuck Norris look smaller.

The key stakeholders of program were directors of the company, one more important than other (with all the honorific titles): Chief of Products, Chief Marketing, Chief IT, Chief Engineering, Chief Operations, Chief Executive of Executives, etc. All were making budget plans, products strategy based on whatever I am to delivered in the next 4 months. How I am going to achieve all the objectives in time knowing there are ten major risks than can put the objectives at risk?

I was thinking if I would make known the risks to the key stakeholders they will understand we need a collective support, in order to mitigate/solve the risks. I was asking the signoff for projects plan with all the associated risks and apparently everyone was happy. After few months I understood why they were so happy: because no one didn’t read the project plan, but they sign in blind the plan. As Risk Owners there were three of the executives, whom they were asked to minimize the risks associated to resource allocation (either by hiring staff, either by approving overtime work), to reduce the product scope (it was needed a renegotiation of scope for marketing deadlines), to approve extra budgets for unforeseen risks. But all these aspects apparently “minor” they were missed by key stakeholders, because they were expected to be solved by me.

Unhandled risks by Risk Owners, of course lead to new risks. And while project was developed I have found more an more risks. My superior, one of the directors asked me:

-What are those new risks? Where they came from? You don’t manage the project good enough.

At one moment, I rise the following risk: the scope of the products is change on daily basis and this will impact the main objectives. But everyone thought I only exaggerate or was a ill will and of course the risk was ignored. Seeing no one assume the project risks, I wasn’t count them anymore. I was handing the problems as they appear, in “Agile” style, on daily basis. And that’s how I started to assume the role of SuperMan that solve the problems “on the fly“. Everything was amusing and challenging for me, until one day when CEO was asking a project status. When he understood we will push the marketing deadline by two weeks (two weeks was nothing compared to problems we encountered, how much money we saved because they didn’t have to pay the overtime worked), he said: I am unhappy with the Program Manager. This delay is unacceptable! When CEO make a crisis of this, all the others directors entered also in fibrillations, because their job was at stake and they become suddenly very attentive to project development.

One day a new risk has appeared from sky (just one month before the official release): if we don’t obtain the Microsoft certification for windows store as it was planned, we could not launch the products for windows in time. There was also another risk that Microsoft we could have delayed the update for windows 8.1 and this also might impact the update for security components, but fortunately this risk didn’t materialize and we found an workaround the Microsoft issues so few users were impacted when they updated the windows. But to solve this problems the entire company entered in withdrawals spasm, because this risks have a impact on a lot of existing users. Entire story cost us an entire weekend with all the technical team.

What are the lessons learned from these stories?

I can tell you from the beginning few have learned from this experience. In all this, I was found guilty, as I was the Program Manager. There are few lessons that can be learned:

Lesson 1 about how risks are registered. Few knows what mandatory components a risk should have in the Risk Register: risk description, impact, probability of impact, quantification of impact (in money, resources, scope, customer satisfaction, etc), risk category (urgent, medium, low importance, etc), mitigation solutions (eventually a plan with two solution and one is backup), Risk Owner (who will be responsible with risk), Risk status and we can add few others component depending on organization.

Lesson 2. No One like the risks and no one wants to hear about risks. So we need to pay extra attention on how we communicate the risks. Before you send a Risk Register via email, with 20 risks inside (where 5 of them are critical, 10 medium), it is needed some preparation meetings (information and awareness of Sponsor, of customers or key stakeholders).

Lesson 3. Known risks recorded in Risk Register have quantified impact expressed in money or manhours, time, resources, scope, etc. These risks are always added to project plans (budget, timeline, etc). There are few managers they are adding risks properly to project plans (i.e.: budget plan always contains also money allocated to solve known risks; timeline always contains activities for monitoring known risks). Most of PM when create the budget plan instead of evaluating risks, they are adding 30% extra to development cost and say that’s the budget (including risks). Beside this practice does not represent a realistic (why 30% and not 15% or 85%?) does not justify on what exactly the money will be spent. The Budget associated with known risks is known as Contingency Reserves and is managed directly by Project Manager.

Lesson 4. Unknown Risks. These risks can’t be prevented and most of the time, when you figure out about them is too late or you can do little or nothing about. The best method to avoid or solve this problems (risks) is a good communication with project Sponsor (if you have a good relation with him, when a problem will occur will be more simpler to accept it and to offer you help). The risks from this category can’t be defined or quantified, that’s why they are added to project’s budget as a buffer called Management Reserves. Also the budget estimation for new potential projects (pre-sales operations) they always need to include management reserves estimations (no matter the specified form: manhours, resources, money, etc). This budget is always managed by Sponsor or by Project Manager, if he has the designated authority from Sponsor.

Lesson 5. The lack of risk management or a poor risk management is a risk itself. Also, by eliminating the activities associated with risk management in order to minimize project budget or timeline, actually can increase the overall budget or the duration of project. The activities of Risk Management are tasks that cannot be removed from project plan (they have a cost, a duration and dependencies associated). In other words, the elimination of a risk by force, imply another risk. See the story of Can someone tell a PM how to do his job?

Lesson 6. Agile is a risk itself. When I received the role of Program Manager, it was given me the mission of implementing Agile in company. To understand what does this mean, try to image the following: the number of people working on projects were 50+, spread in different departments (R&D, QA, IT, Marketing, Release, Fulfillment, Support, etc). Despite some of them don’t know how to “eat” Agile or didn’t received an appropriate Agile training, the internal organization of departments didn’t permit working Agile (the teams were located on different floors, the working hours were different, the tools were different, the process were different etc.). In these conditions, I tried Agile implementation only in R&D and QA department, and that was also a challenging mission: the team had a natural resistance to change (there were people for nine years in the company were never had a Project Manager; they were born outlaws, frenzied against non-performance management, hating any form of organization, Agile or traditional). Finally, I managed to implement a simplified form of Agile. But as you may know, the concept of Risk Management does not exist in Agile (usually Agile handle risks using the concept “manage the problem as you go“), but on a big project with huge tasks and resource dependencies this strategy of “manage as you go” can be troubling (some problems/risks need to be prevented with 4-5 months before they happen, while focus on Agile is at most 1 month in advance; also, I observed in practice, the Agile teams don’t bother too much with risk management excepting daily scrum meeting and, even then, the risks are treated inappropriate). As I shown before, the lack of risk management is a risk itself, and a framework Agile without a suitable risk management is a risk itself.

Risk Register Sample

The theory told us what are the steps in completing a risk register: Risk Identification, Qualitative Analysis (without exact figures), Quantitative Analysis (precise figures), Offering solutions and update the risk status. I will not enter in detail how the risks are identified, because each of us without realising make a continuous risk identification (in daily meetings, in smoking breaks, through colleagues feedback, auto-analysis etc.), but I will describe two aspects most of PMs do not pay attention: Qualitative and Quantitative analysis.

The qualitative analysis does not offer precise figures but a relative value of risks (Impact and Probability). By multiplying the two values can be obtained a relative number representing how important is the risk and how soon should be handled. Usually only the important risks are handled first and they are moved in quantitative analysis stage, but is recommended to perform quantitative analysis to all identified risks no matter how unimportant might look. Here is how a quantitative analysis looks like:

The most important aspect need to be underlined in quantitative analysis are the details of impact on cost, time, scope and on all the constraints. A method used in Quantitative Analysis is Expected Monetary Value Tree or EMV (do not confused with EVM=Earned Value Management) which calculates the best decision tree (the decision tree are complementary, meaning the decisions are mutually exclusive). Each decision tree have an Impact(I) and a Probability (P). EMV=I*P.

Here is how a Risk Register looks like with all the data integrated:

Note: the importance of risks are usually marked using RGA notation (Red, Green, Amber).

Expected Monetary Value Sample

How we decide what is the best decision when we have multiple solution/plans to solve/mitigate the risks? Let’s take the following example: The evaluation of new change requests can add 100 hours extra to the project budget. Because is only about 100h over the budget, and because we don’t want to put unnecessary pressure on relation between clients and company, the question is if it worths the negotiation with the client to ask for an approval of 100h extra budget for change requests or the company should assume the costs (being part of cost of sales)? We have two decision trees:

Tree 1 (solution 1). Company accepts the costs. Probability of exceed the budget is 60%, the impact 100h and 40% probability the extra effort will not impact the budget (no cost associated). So, EVM1 = 60%*100+40%*0=60 manhours.

Tree 2 (solution 2). The company do not assume the cost. According to contract we can negotiate the cost; client can support 50%-100% of total cost. Impact: 100h. Here we have multiple decision trees with different cost: in the worst case the company cost will be 50%*100 =50h and in the best case is zero (when client accepts 100% of costs). EVM2 = maximum cost EVM = 50%*100h = 50 manhours.

Because EVM2<EVM2, solution 2 is better and worth implementation.

Final notes

In Risk Register each risks has associated a recommended solution to avoid, mitigate or solve the problem. The solution is usually provided in Contingency Plan column. If this solution does not work we should have a Fallback plan (a backup plan). Theoretically, the budget for Contingency Plan and Fallback Plan need to be covered by Contingency Reserves budget managed by Project Manager which is allocated at the beginning of the sprint/phase/project, but the risk impact can increase in time and, in this way, making the budget insufficient for managing the known risks; if Contingency Reserve is not enough to solve the risk, we can use Management Reserves, if Sponsor approves.

Because the risks can have an impact on project budget, the Contingency Reserves and Management Reserves need to be added in pre-sales offer (in request-offer/bid process), to avoid renegotiation of extra budget during the project (for unforeseen risks).

The Risk Management used for projects, can be used for programs and in business operations in general.