This post will be a little bit more “roaming through knowledge” than the usual.
Actually, it is part of a series, first published in May 2009.
But, following the dictum of somebody else, I will make things as simple as possible, but not simpler.
What is the point? Talking about ways of representing and forecasting the expected decisions of groups and individuals, and some projects that try to build a “model” of what we are and could be- be it our DNA or our brain.
And, while doing this, recalling some useful concepts that you can apply in whatever you do in your business and personal life- including when you are on the receiving end of the results of a model.
As usual- theory is converted into (hopefully) plain English, and the examples are from real life and experience in business, politics, technology- and their impact on personal and business life.
PREVIOUSLY
GMN2009: PROGRESS
You do not need to know just what you are supposed to do, but also where you are, and where you should be.
If you are a perfect project manager with all the certifications required: probably you should skip this section, as it could be depressingly simple.
But it is not just progress itself- is the measuring and definition of progress that matter.
GMN2009: RISK
If you identify the “risks”, what could affect the conditions that you assumed that could affect your execution of the plan, then you will end up monitoring that:
- you are using the resources identified if, when, how planned
- the risks you already decided to keep under control
- whatever new happens around you that could affect your plan
- last but not least: that the activity you planned for still makes sense
It is not just the journey that you have to keep in check; it is also the destination.
Before discussing risk, let’s consider the context of risk.
If any activity is considered over time, you will find that it contains a certain number of activities that have (or should have) a beginning and an end- projects, in the wider sense.
Yes, the standard definition of a project, given also in previous sections of this series, is that a project is a one-off, not a continued activity.
But, to discuss what could affect your activities (risk or opportunity), I will require you to reduce the problem of identifying, monitoring, assessing, controlling risks in any activity to the smaller issue of linking risks to the lifecycle of an activity with a beginning, an end, and, usually, one or more results
The results could then, partially or not, be used to influence the future repetition of the activity- a process that we call normally “learning”.
Well, at least- in normal life.
How many organizations do you know that, whenever they do something, have the discipline to summarize whatever they learned, so that it can be used to identify in the future similar occurrences?
Few.
Instead, this is what you would expect as a normal behavior from any person.
As it was in “progress” (see GMN2009: PROGRESS), to manage the lifecycle of risk you need to have a framework of reference.
If you pick up any recent (i.e. from early 1990s on) book on project management, you will find plenty of material and discussions on risk management, key performance indicators (KPI), and so on (see GMN2009: PROGRESS).
As it is easier to classify, structure, organize something that can be represented quantitatively, over the last two decades the literature on “risk management” has grown into an industry.
And also project management, while striving to become a science, got more than its fair share of “quantitative analysis”.
The first two books that I studied by chance, after one of my usual visit to bookstores, were, again by chance, both published from two UN entity, the International Labour Organizaion (ILO) and the UN International Development Organization (UNIDO).
The two books are: “Management consulting”, by Milan Kubr, and “Feasibility Study”, by UNIDO.
What is interesting about these books is that both are eminently pragmatic and well structured.
As a side-effect: both are almost ageless “Management consulting” was first published in 1979- its main guidelines still old true).
And that could be said of few of the crop of project management books that has been published since early 1990s.
If you get a non-quantitative book on project management, you will be able to build the proper framework to identify what is risk.
Starting with a more modern crop, you risk of seeing tons of details- but not seeing the “system” as a comprehensive whole.
If you want- you see and control the trees, without seeing the forest (and its surrounding environment).
Having defined the context of risk, how do you identify risk?.
Risk is, by definition, a potential effect- not necessarily an expected result of your activities.
Each industry has some issues specific to its own activities.
Again- risk is related to something you do.
Do nothing, and you have a certainty: that you are doing nothing, and nothing affects what you do not do.
Therefore, whatever your activity: you will never have zero risk.
Probably, in your industry you can find references for the standard risks to assume present and that you should monitor.
But I invite you to take a step back.
Ideally, if you are in charge of defining a plan and managing a project and the associated risks, you should already receive a rough risk definition.
Because, if your project does exist… somebody has decided that it was to be done.
And, hopefully, talked with the stakeholders (see GMN2009: CHANGE), to understand not only what they expect, but also to negotiate what need to be done.
And, therefore, to understand what could affect the mutual interests of the involved stakeholders- and the ensuing project.
A small example.
Years ago, I was called by a partner to take over the management of a customer that had threatened a lawsuit.
The reason? A software used in production maintenance scheduling (when each machine is controlled, and what are the results) stopped working.
What I discovered was quite simple: nobody had bothered to build an agreement into the contract that gave limits to how the software was used, and what should be done, and how fast any intervention was done, or… many more details 
So, my customer management activity became a crisis management.
The first step? Meet the stakeholders, and collect the risks that they themselves identified.
Then, I considered these, along with other parameters, to identify a negotiating strategy that balanced all the risks vs. the certainty of legal costs, and to identify something that is often forgotten when discussing risks.
The end result? My partner accepted to lose a little bit of money to make some changes, under my control, but in exchange we had two further projects (while I was there), with a total value that was a multiple of the original project that generated the risk of a litigation.
Not every risk has only potential negative outcomes.
Some risks could actually affect the viability of something that you had planned to do. And remove the need.
And, along with the need, free the resources to do something different.
I lost count of how many projects that I received to manage had a “charter” that had undergone so many approval steps, that time had taken over the viability or need or desirability of certain “outcomes”.
The main point is: the “risk framework” has to be identified while the “project charter” is being defined.
If you have a project, but you do not have an identification of the risks- do it yourself at the earliest convenience, and have a formal or informal approval of the list that you produce.
And once you identify it, you are ready not to manage, but to set up what is needed to monitor risk.
Over the last 20 years the approach to risk management adopted for activities moved from being confined to certain activities (insurance, banking), to a greater visibility for the financial risks (also ignoring 2008-2009)- and a widespread adoption of their approach also in other activities.
My first exposure to financial risk management was in early 1990s, in Italy, through some projects involving the Centrale dei Rischi, a centralized data bank (If you want to know more about how it works, you can go on the website for “Banca d’Italia”).
In 1990s, every bank contributed a certain set of information about its customers, and got back from the system the aggregate information about all the banking system, plus details about their own customers, and a feature to pay to obtain information about potential customers exposure toward the financial system.
It was linked to lending risk. And therefore it was heavily focused on quantitative information.
In 2008 it became quite common to read on newspapers about “Basel II”, an agreement updated in 2001 of a previous agreement of 1988, to regulate commercial banks that operate internationally.
Interestingly, from early 1990s the concept of “risk management” used outside the financial industry veered toward the quantitative (number-driven), forgetting the previous qualitative (e.g. organization, structure) management of risk.
This concept was based on the 1988 agreement in Basel- mainly numbers.
But then, in the 1990s, there were discussions in the financial industry that stated that quantitative risk was not enough.
The Basel II agreement introduced into the “quantitative” approach (minimum capital reserve to cover the credit, market, operational risk), few qualitative aspects (supervisory review process and market discipline).
If you work inside an organization that adopted PMI or PRINCE2, you are supposed to follow a similar approach: numbers are not enough.
A basic, minimal setup to manage risk is quite simple: negotiate a single point of reference within the project (preferably: who is managing the project) and within each stakeholder organization to provide information on the risks.
While preparing the plan for the project (or reviewing it, if you received one along with the responsibility of the project), you should identify the risks as discussed above, and then identify priorities and measures.
Usually, this will impact on the plan- therefore, the final plan, built after the risk-management negotiation and before starting the real activities, could be quite different from what you expected.
Your stakeholders can be your best allies, as they have the knowledge on what could affect your project- and could, in their own way, provide you feed-back on any evolution.
To avoid over-communicating, usually anyway, unless there is a formal structure in place to manage risks across projects, I negotiate one single point of reference for the decisions of the collective decisions and evolution of the stakeholder-provided information.
Another part that is often forgotten: if allowed, pay a visit to any organization that supports projects across your organization; as an example: quality, internal audit, knowledge management, etc.
Why? To give a few minutes presentation on your project, and then get from them feed-back on the “state of the art” of what could affect your risk assessment and monitoring.
In which order should these preliminary activities carried out? It really depends. On your organization, on your status, and so on.
If the preparation activities are done, then you can prepare for the collection of risk-monitoring information.
In the introduction I referred only to the risks that are related to your plan:
- you are using the resources identified if, when, how planned
- the risks you already decided to keep under control
- whatever new happens around you that could affect your plan
- last but not least: that the activity you planned for still makes sense
If you try to convert these classes of risk into something that can be measured… you will discover that many are non-quantitative.
Not only that: the list that you built with your stakeholder approval and that influenced or generated your planning will also be your guideline to decide which information you should keep monitoring.
But the description of a real risk management experience
Few years ago, I was asked to be a project manager for a partner on a project in the government industry that involved some special regulations, that are set at the European level, but then implemented locally, and require an exchange of information.
My first task, following my own rules, was to revise the plan- because the person that had created the plan wasn’t part of the project team.
Next, I revised what was supposed to be produced according to the plan, after studying (luckily, I am a quick study at contracts and laws) all the documentation and laws referred to as the framework of the project.
This activity allowed to identify additional risks- in some cases, I would say more “red flags” than just risks.
Then, I asked to my partner to confirm that I had the authority to bring the matter to the buyer, and renegotiate the plan, within the assigned budget.
After a negotiation to remove some requirements and add some others, and change the order of some activities, I was able to prepare the quality plan for the project.
Informally, as there was a conflicting set of quality rules (from the contract, from my partner, from the customer usual work procedures).
The project required infrastructure- but then, I was told that the infrastructure for the development wasn’t really for us: it was shared with others.
After the first issue, I had to build a “fall back” plan, that involved having a portable PC with all the software installed, in case there was an interruption during the preliminary presentation to the customer of the first version.
But all during the project: before every meeting I scheduled the meeting and, if provided, sent the invitations.
After each meeting, I produced three levels of minutes: for the customer, for my partner, and for myself.
Using as a reference the milestones set on the project plan, I constantly also monitored the appropriate time to organize a “progress meeting” before the milestones, allowing to reschedule or re-plan activities.
In preparation of each meeting, beside asking to the team members the last updates, I reviewed from the log the evolution of the information that I had collected from my team or obtained by the customer since the last meeting.
This preparation was completed usually with a mental “bullet list” or formal “agenda” to discuss, along with a five-minutes mental speech containing my line of reasoning and proposals.
Did I deliver the five minutes speech as such? Almost never. I used it instead, along with the formal “agenda” or informal “bullet list”, as a “thread” across the meeting- that was almost always indirectly structured as a brainstorming.
Without saying so, and without being that formal, my approach to the “progress report” meetings is to discuss not just the numbers, but also the risks and their evolution, notably if something is changing outside that could impact the project (e.g. in my case: the privacy laws, as there was a recent update that also the “expert” on the matter was not aware of).
If you work often as a negotiator or “creative”< you have probably your own way of guiding the meetings>
Otherwise, I suggest that you read “six thinking hats” of E. De Bono, so that you learn how to separate the “vent the frustration” time from the “this is the information available” and the “each one contribute ideas”.
There were ups and downs, over its life- but, when I was told that the project had been selected for the QA review… I was able to deliver a CD containing all the documentation on the project, its history, the material (including training multimedia) produced, the test, and so on. And it took few hours to prepare it.
To summarize, what is the lifecycle of risk monitoring
If you are formally trained in risk in your industry, you have certainly a “lifecycle” of reference.
The simplest one, with the widest application (under different names) is the Plan-Do-check-Act (PDCA) cycle.
Plan what you want to do, Do it, Check what is the result, and Act to feed again the PDCA.
If you re-read the description of a practical project above, you will see that this is the cycle that I followed.
Not just for the project- but for each step.
Including for the monitoring of each risk.
First, I planned the monitoring of a specific risk, say, the change in a relevant legislation (PLAN).
Then, I kept being updated/monitoring changing in the relevant law (DO).
Then, whenever I identified a potential change, I checked to see if that impacted (CHECK).
Finally, whenever there was a change that I assumed could affect the activities- I reviewed the plan to see what the impacts could be, and started a verification of the impact first with my team and partner, and then with the customer (again, a PDCA cycle, started with the ACT on the results of the original cycle).
A common mistake made by many junior project managers is to start with all the plans required (communication, production, risk management, quality, etc).
And then, as soon as things get on course… abandon what they assume that can be done without.
The idea of managing risk is that you keep monitoring not only the “now”, but also how are you faring vs the original framework of reference.
If you had a long list to start with, you can shorten the list only if authorized by whoever authorized the initial list; frankly- to err on the side of caution, I stay with the original list until the end of the project, unless requested otherwise, by the signing parties.
Working inside an organization has a beneficial side-effect: the lessons learned by each project can be shared in the same organization, as it can be assumed that most of the conditions linked to the organization way of working, or its business, will benefit from what you learn in one project.
If you are a professional project manager, working for different customers, there is only one organization that could really benefit from the lessons learned: your own.
One of the reasons of not changing the risk management profile, unless requested to do so, is that when you are in the middle of the activities you lose the perspective that you had before planning the activities- and you actually increase the risk, by potentially removing some monitoring activities because it seems, at the time, not useful.
If you are able to control the risk monitoring, then you can actually move one step forward, toward risk management.
The PDCA cycle described above can be used just for monitoring- or can also influence the evolution of the risk policies and activities, bringing risk management.
In my view, you are managing risk if all the organization is able to benefit from the lessons learned.
And this requires having a structured approach to the collection of the information about how each project structured and organized risk.
This usually implies creating some “system” (usually with software, rules, training) to manage risk, so that each project is required to monitor certain issues.
What is the difference?
If you manage risk project-by-project, every project will start from scratch to identify the risks- and maybe the proper management of risk will depend also on the luck in selecting the right stakeholders.
If you risk management is across the organization, the most experienced project managers will focus on negotiating a selection of the risk to monitor, and some additional risks.
But, thanks to a framework of reference, also junior project managers (or project managers that are usually doing non-project management activities) will be able to start with something that can be used for both each project and the organization benefit; at worse, they will monitor more than they really need.
Getting back to reality
Moving to your private life: if you plan to spend some time on the beach side, doing nothing- just laying down in the sun, would you still go there if there is a tornado coming through?
Probably- if it were just rain; but with a tornado? Well, also if you already paid for that vacation, maybe you will barter the certainty of losing the money that you already spent with the certainty of finding yourself in the middle of a disaster area
At the beginning of this section I wrote that understanding risk management becomes easier if you focus on a simpler version of reality, the project.
In the next section, I will write about building models that can cope with a changing reality.
NEXT
GMN2009: REALITY
When you build a model of reality, you try to reduce complexity.
Reducing complexity means making choices- and reducing the risk of something unexpected affecting the results of your model.
Actually, it means also reducing the number of parameters- and, therefore, making any evolution in your world more predictable.
But reality is not necessarily limited by your definition: and managing the reality within a model requires more that planning beforehand for what you know, in terms of activities or risks.
You have also to identify what is the “normal” way in which your model will react to unexpected changes in the “reality” surrounding your model.
Tags: gmn2009, indicator, key, kpi, management, methodology, model, monitor, monitoring, negotiation, organization, performance, plan, planning, risk, stakeholder