As part of my degree I am currently considering the different methods available for use when performing a risk assessment. The techniques I have actual experience with for the identification of risks are stakeholder interviews, brainstorming and referring to checklists. Though I have not used these methods directly for “risk assessment”, I have used them extensively for opportunity exploration in product and interface design. One of the roles I fill at work is that of interface designer, I identify problems and opportunities for the continuous improvement of our custom built online ordering software, I talk to the users, collect their requests and requirements and then I explore options for solutions, build the design brief and send it to our programmer. On consideration, the risk I am always trying to avoid is making changes and attempted improvements to the software which don’t meet the needs of the user. This seems to be very similar to identifying risks for a project.
In my experience going directly to the subject matter experts, being the customer service team, the actual system users, and other stakeholders is a very effective approach to gathering quantitative information. In fact without the input of these stakeholders most of what I am working off is gut feeling, which can be sometimes right and sometimes it can be very wrong. In my experience I believe the gut feeling of the project co-ordinator/manager would not be the most effective tool for uncovering problems and solutions, because they only know what they know, they can not speak from the user’s perspective or from the clients perspective, in my role personally without the input of these stakeholders I can only guess. Surprising, interesting and important opportunities can be missed.
Stakeholders have a direct interest in the success of the project, they know what they want from it and they know what their concerns are. Their input steers you in the right direction for uncovering the root cause of problems and potential solutions. One of the best pieces of advice I was ever given was to ask the user a provocative question, and then follow up their answer with “why?”, and the next answer with another variation of “Why?”, etc until you come to the root cause of the driver for an opinion, behaviour or request.
One of the challenges of interviewing and brainstorming for this kind of information is the sheer amount of qualitative information you get from your interviewees. If you don’t take time out to analyse and pick out the relevant parts immediately after the session while its still fresh in your mind (at that point pulling out insights is pretty easy) and instead you compile a number of interviews before beginning the process of analysing and defining you can be faced with quite a challenge in processing the data you have just collected. When I first started interviewing stakeholders I made the mistake of viewing interviews as the first phase, and theming and defining as the second phase. I went through a bunch of interviews and brainstorming sessions and I was left with a tremendous amount of information to sift through and try to make sense of, I learnt I should have summarised the key findings from each session immediately. Not doing so made the entire task a lot more tedious than it should have been.
Now I break each interview or brainstorming session down into its key themes, I record any requests and surprising bits of information, and anything I had not thought of, I take note of the opportunities highlighted immediately, this makes the process of interviewing stakeholders much more useful and less overwhelming.
Checklists found online and those such as usability heuristics can be useful to some extent, but I am an avid believer in testing the things learnt from checklists and such with users to ensure they are actually relevant.
A lovely story, and a great example of how brainstorming sessions can be key to solving important problems is the story “A Problem of Ice, Bears, and Honey Pots” which details how an unexpected insight from a brainstorming session solved one of the organisations biggest problems. Here is a link if you would like to have a read: http://www.managetrainlearn.com/page/group-creativity
There are some lessons it is difficult to learn without actually experiencing failure and successes first hand, and looking to your team and your stakeholders for insights has proved, for me, to be one of them.
‘In Endymion, I leaped headlong into the sea and became better acquainted with the soundings, the quick-sands and the rocks than if I had stayed upon the green shore and took tea and comfortable advice.’ | John Keats