Checklists

Checklists and questionnaires belong in the toolbox of risk professionals. A checklist works best when used by the risk professional while interviewing an information source, whom we’ll call an interviewee. 

The checklist becomes far less effective when simply handed over to the interviewee because when you let the interview work by himself,  it raises new undesirable dynamics:

• First, the interviewee loses the chance to ask questions about the questions being asked.  He may misunderstand what is being asked, but unaware of it.  In such a case, even if you informed the interviewee that they should ‘feel free’ to ask if they have questions, will not help much, because in this case, the interviewee is not even aware that they misunderstand.
• Second, the interviewee may not have as much interest as the interviewer in the process of gathering data.  In cases like this, you can expect that only the minimum amount of information will be written down in the checklist.
• Third, the interviewee may not see the whole point of the interview, and why they must fill in the checklist. As in the second dynamic above, this results in lacking information.
• Fourth, a large number of checklists and forms are very badly designed, which can easily lead an interviewee to confusion. Many forms ask for too many things. The interviewer may have energy to fill in the first few entries, but a noticeable drop in energy due to a drop in interest can often be seen.

A well designed form helps much toward eliciting good information.  At the very least, the following should be addressed when designing questionnaires and checklists:

• Who is going to use the contents of the checklist?
• To what purpose are they going to use the contents?
• Who is going to provide information to the checklists? (That is, who are the interviewees)
• What kind of questions and prompts should the checklist contain in order to elicit the information required?
• What kind of information does the current version of the checklist contain that are not needed?
• In what ways can the questions and prompts be misunderstood?

It is vital that a checklist be tested on several interviewees first before finalising it use.

Risk Management Software Packages

In a LinkedIn discussion someone asked for recommendations on a web-based risk management software package that’s suitable for a SME (small to medium enterprise).  The key need was for managing a risk register and for tracking risks.  Some of the recommendations were:

• @Risk (http://www.palisade.com/risk/)
• Balanced RiskCard (http://www.riskcard.co.uk/)
• Active Risk Manager (www.strategicthought.com)
• Link ResQ (http://www.linkresq.ie)
• RiskAid or RiskAid Enterprise (http://www.riskreasoning.co.uk/)
• STREAM (www.acuityrm.com)
• Covalent Enterprise Risk Manager (http://www.covalentsoftware.com/product/erm/)
• EsyRiskManager (http://www.dnv.com/)
• Pims (www.omega.no)
• JCAD RISK (www.jcad.com)
• Magique (www.magiquegalileo.com)
• Aon RiskConsole (http://www.aon.com/denmark/en/esolutions/aon-risk-console.jsp)
• RiskyProject (http://www.intaver.com/riskyprojectprof.html)
• (http://www.align-alytics.com/)  (what product?)

This is quite a handful of choices. I’m hoping to be able to spend some time lokking into each one.

An approach to planning

Planning a project involves identifying the activities required to deliver the project and the inter-dependencies between those activities.  These activities and the dependencies are then modelled onto a network diagram.

Task duration estimates are often padded, as a matter of good practice, but also as a matter of covering one's behind.  Things often don't go according to plan and one has to allow for that.  If I estimate that task A will take 10 days, and I say it will take 10 days, and then something goes wrong, then not only do I look bad, I might also I end up delaying the next task which was set to begin 10 days later.  So the common practice is to be generous with our estimates and pad them for contingencies.  Such padding implicitly addresses the risks faced.  

There is another approach that integrates project schedules with risk management, and at the same time highlights the possible sources of these risks.

One way to bring this planning to a different level is to first make a realistic and optimistic estimate of how long each task will take.  Let's say if a task will take 7 days if no problems occur, then we start with 7. We do the same for each task. Then we study the task and its dependencies and try to understand what could go wrong that can cause its accomplishment to exceed 7 days.  Then we try to address those things that can go wrong.

Let's say the person doing the task will normally take 7 days to accomplish this task, but has other stuff on his plate, therefore it may take more that 7 days for him to complete the task.  Why?  Because his time and attention could be diverted to the other tasks.  If we don't highlight this reason then we can't manage it.  Suppose we identified that this person really has other stuff on his plate, then we can take steps.  We can schedule his task to be done after he has finished his other stuff, or we can arrange things so that he suspends work on other stuff, or we can just accept things as they are and simply pad the number of days.  At the very least, we have identified a possible cause of problems.  

There could be other factors to consider: this person could get sick during that time, his machine might break down, he could misunderstand the specifications,  or what's required of him and then we will need to redo things, and so on.

By thinking through the possible reasons for exceeding the optimistic estimate, we begin to identify possible causes of delays and we begin to be able to plan for those causes: try to minimize their chances of occurring, minimize the impact if they occur, etc..

Project management

Any undertaking, no matter how small, faces the possibility of taking longer than anticipated and costing more than expected. In addition, there also exists the danger that the job will not be done right. Or if indeed done right, was not what we thought was needed.

The bigger the undertaking, the bigger the likelihood of unwanted problems occurring.  The culprit is complexity.

Consider the undertaking of changing your shower curtain versus the problem of defending Normandy beach from Allied invasion.  Yes, you might slip on the floor and bang your head while doing the former, many, many more things could go wrong in the latter (and many did).

One is more complicated than the other. It is this (vast) difference in complexity that makes the other undertaking much more likely to have potential problems. Complexity is like having open doors and windows where problems are free to let themselves in. The more complex the undertaking, the more numerous the open doors and windows.

We could stay small and be content with simple undertakings, but our society's progress will be limited. We can choose to limit our undertakings to nothing more complex than mastering the art of candle-making, but our society will not progress much. If we want progress, we have to face complexity. 

Fortunately, we have tools at our disposal. 

Look at the skyscrapers and other technological marvels we now have.  Science and engineering has progressed such that it is now possible to design buildings that will not randomly fall down. We now know how to design such buildings. Complexity and its associated problems have been reduced by scientific and engineering knowledge.
But we like to push the envelope, and so complexity remains.

Every undertaking requires activities. No activity, no undertaking. The more complex the undertaking, the more numerous and varied the activities are.

Activities depend on and interact with other activities, and therefore must be coordinated. Those who need to fit glass windows to a building cannot start working until the building structure has been built. Those who need to test software cannot begin until there is some software to test.

Knowing how to design a building is not the same as knowing how to organise the activities required to build that building, and vice versa. They're not the same thing.  The training, skills, and mindset is different. The orchestration of these activities demand a different kind of knowledge, attention, and discipline from that required to design a building.

To harness the benefits of science and engineering, there is another discipline that was developed to help us with our complex undertakings. This discipline is intended to help us manage the activities and ensure that:

• We can have a confident estimation how long a undertaking will take, so we can plan for it.

• We can have a confident estimation how much the undertaking will cost

• We can identify the activities required to complete the undertaking.

• We can ensure that the undertaking will take no longer than planned

• We can ensure that the undertaking will cost no more than planned.

• We can ensure that the undertaking will be completed.

• Everyone's valid expectations are met.

That discipline is called Project Management.

What is the difference between an impact and a risk?

Sit at any Risk Management 101 class or Risk Management introductory workshop and you will most certainly be introduced to the risk register. And in that risk register, you will be introduced to two columns: the Risk, and the Impact. 

You will be told that the Risk is an event that may or may not happen.  You will also be told that Impact is what will happen if the Risk occurs (or ‘eventuates’). Sounds clear, simple, direct. 

Now let’s apply what we’ve learned.  You are concerned (rightly) about crashing your car. Is that a risk? Or is it an impact?  (Avoiding the pun on crash and impact). It is not certain that your car will crash, so that is a risk.  What will be the impact?  Easy: you may experience fatality.  Or you may experience serious injury, or you may experience light injury. 

But why isn’t crashing the car an Impact? 

What caused the car crash? Did your brakes malfunction?  Was that a risk?  Was there a risk that your brakes would malfunction?  Were you hit by a drunken driver? Was that a risk you faced when you were driving? Absolutely.

So let’s say: Risk = Possibility of being hit by a drunker driver.  What is the impact?  Crashing your car.  What was the risk earlier is now the impact.

The distinction between risk and impact is not so clear.  What is a risk from one perspective is an impact from another.  But which perspective is the right one to take? And which perspective should you be taking when you fill in the risk register?  Do you put “Car crash” under Risk or under Impact?

Winning and Risk Management

There’s a highly-regarded self-coaching book called “Sail, Race, and Win”, by Eric Twiname and Cathy Foster. In the book is a neat description of how to win in a race.  They ask the reader to imagine a descending escalator, with lots of people, representing the competitors, walking up the escalator.  The goal being to remain in the same spot they started in as much as they could manage to. They can walk up to the same pace that the escalator is going down, but they can't walk up faster than that.

Since no one’s allowed to go faster than the pace of the escalator, the would-be winner will have to focus on not making mistakes rather than walking faster than the pace of the escalator.  Any mistake, no matter how momentary, will set you back a little, possibly allowing someone behind to move out in front of you.  The more mistakes and lapses you make, the more you are pushed back relative to your starting position, and relative to the other competitors.

Now since you can't go faster than the pace of the escalator, you can't make up the distance you lost by putting in extra effort. The best you can do is to make no more mistakes.  The only way you can get ahead of those in front of you is if they make mistakes.

I haven’t seen winning explained in this manner before, and despite its oddness, it has a certain valid point.  Twiname and Foster come from the world of sailing.  Perhaps the idea of not being able to outpace the escalator comes from their world, where your progress depends on the winds and the tides -- you can't go faster than what the elements or the environment allows.

The image seems rather useful when thinking about how risk impacts business.  A company cannot make more money than what its environment allows.  For example, if you are a consumer goods company, how much you can sell is moderated by the size of your market, the demand for your product, and the competitive dynamics of the industry you are in. In a market with 10,000 customers and 5 competitors, you just cannot make sales equivalent to a market of 20,000 customers.

And while you can't get ahead, you can definitely be set back.  The key to winning then becomes minimising the setbacks. From an operational basis, you are constantly being set back if your production costs are more than the competition’s. From a discrete and pulsating basis, you are set back each time a risk eventuates which impacts you negatively.  The longer and more expensive it takes you to recover, the more you are set back.  The key to winning in this case is to ensure that you minimise your risk eventuations and minimise their impacts.

You can look at risks as these setbacks.  It is in your interest to avoid them as much as possible, and to be able to recover as quickly as possible.  Even then, you can only recover to a point less better than where you started. Hence, reducing the occurrences of risks become a key factor in winning.

Is managing a project like conducting an orchestra?

Managing a project is so frequently compared to conducting an orchestra that the comparison has almost become a cliché. 

I understand the comparison. There is a slight similarity between conducting an orchestra and managing a project. The similarity lies in the fact that both the conductor and the project manager do not make the actual product. They simply orchestrate the work of those who produce.: a conductor controls the performance of many different specialists, combining the individual performances into one single harmonic product.

There are a couple of key differences though.

The first difference is that an orchestra has had time to rehearse and practice over and over exactly what they are supposed to do. Indeed, they must refine their work until it is flawless, before the actual live execution.  A project team hasn't got that luxury.  It has only one pass at executing the project.  

An orchestra will never be asked to work faster, redo a task, or cut the scope of a musical piece.  There is no such thing as crashing the music by playing faster.  Project teams have deadlines to meet and often need to redo work and work faster than normal.  An orchestra performance is an operation. It is perhaps the smoothest of operations.  There is no change of plans.  The audience's (stakeholders) mood will not change what the orchestra will play or how they play it.

But then again, why use a conductor as the focus of an analogy? Every orchestra presentation has an actual project manager orchestrating it, scheduling the rehearsals, picking the team, picking the conductor, selecting alternate members, etc. 

I think a more appropriate example is that of a coach in a basketball game.  The coach does not deliver the points, he manages the team so that they deliver the points.