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..