David Hillson was our special guest.
Video is here.
This is David’s YouTube channel: @RiskDoctorVideo
Buy David’s books on risk management on Amazon.
Transcript
[00:00:00] Yegor: Everybody, welcome to the next episode of Shift-M podcast where we discuss project management with a specific focus on software engineering, because our audience mostly consists of software engineers, architects, project managers. TodayI’m honored to invite David Hillson who is known as the risk doctor, a famous expert in risk management, which is, in my opinion, the most important area in project management and I would like to ask David to introduce himself right now, say a few words and then we’re going to jump into the question which I have so many for you today.
[00:00:38] David: Well here you go, thank you very much for inviting me to be part of this podcast, it’s a real honor and privilege to be able to share with your many supporters and followers, about what I believe is the most important subject of risk management, I personally believe it’s the most important thing that we can do in our business, in our projects and in our personal lives, and I hope my enthusiasm for risk management will communicate to you and to our listeners during this hour. I’m known as the risk doctor which is a great name because lots of people have heard of the risk doctor but they don’t know that it’s me, so I’ve been involved in risk management for about 35 years, I started in 1985 when I was very much younger and I’m still involved in risk management for two reasons, one is that it works it really helps us to make more successful projects and businesses to stop worrying so much, to sleep better, to be more successful, but also I’m involved in risk management because it’s constantly changing and developing, and I’ve had the privilege to be something of a thought leader in risk management for the last little while just in developing new ideas and and spreading them so that people can use them to be more effective in managing risk in their projects, programs and businesses. So for me as a thought leader that’s one one interesting and important thing, but the other really important thing is that I’m a practitioner, so the ideas have to work in practice, and it’s that combination of new ideas and practical implementation that really excites me about risk management.
[00:02:13] Yegor: Excellent! I actually spent a lot of time after I met you on the PMI podcast, then I spent, I have to say, a few hours for sure listening to your videos on YouTube and I was very surprised by how much I think we understand project management, risk management in the same way, but I would like to start with a story, a funny story. A few weeks ago I posted a question on Twitter, my followers are mostly engineers, programmers, maybe project managers. The question was with a few options, the question was “Do you guys have risk list in your project?” and the answers were grouped in three groups, in three categories, the first answer is “yes, we do have the risk list”, the second one is “no, we don’t have the risk list”, and the third option was “what is a risk list?”, so how do you think where was more than 50% of answers and there were a few hundred people answering that question.
[00:03:11] David: So it was more than 50% who were saying “what is risk”?
[00:03:15] Yegor: Yeah, you’re right, absolutely.
[00:03:18] David: I’m completely shocked.
[00:03:21] Yegor: Why do you think it’s happening, can you analyze this situation?
[00:03:24] David: Well I guess it depends on who you were asking and who was answering your questions, I guess, but to me risk is a natural part of life, it’s something that is part of our ordinary everyday conversation and thinking, particularly at the moment with the pandemic, and with vaccines, and with infection, and do we wear a mask, or do we go out, we’re all thinking about risk exposure all the time, and why would you ever not not think about that in relation to your projects and programs or your software, I can’t understand how people would not think about risk, and so maybe it’s a question of education, maybe it’s a question of process, that the organizations believe that they’re agile and fast-moving and they don’t have time to think about risk, maybe it’s a bravado, you know, we’re professionals and we’re engineers and so, you know, we don’t have any risk. I think there are lots of different reasons, but all of them I think are wrong, there’s no doubt that life is risky, and our projects are risky, and we ought to address it professionally.
[00:04:27] Yegor: Maybe they’re just scared of identifying risks, because I’ve met these situations a few times in my professional life when I was working with software teams, sometimes when you try to identify the risks, that you show this list to your team or to your managers, then they kind of get negative about that and they ask you to hide this list and not think too much about that, maybe that’s something that’s wrong?
[00:04:48] David: Sure, I guess some people think it makes you look weak, it makes you look unprofessional, it means you don’t know what you’re doing, because we’re professional, we shouldn’t have risks, and if you have a risk, then clearly you don’t know what you’re doing, I think that’s completely wrong, because if you identify risk, you can manage it, if you don’t identify it, then you can’t manage it, and then you’re going to be hit by something which is a surprise or a shock, something which you could have seen and which you could have dealt with, but you didn’t deal with, and then I would be afraid of my bosses or my client’s reaction at that point, if they discovered that there was something that I could have known, that I should have known, that I could have dealt with and I didn’t didn’t deal with - then I think they have a right to be angry with me, but it’s not the right response to say “Ah, you’ve identified risks, that’s a bad thing”. If you see it, you can deal with it, and talking about it I think is the best way to get something on the table, so that we can agree what necessary actions there are.
[00:05:48] Yegor: Maybe people are scared of being punished somehow for saying bad things about the future, but in the other hand do you think, in a team, do we need to somehow punish project managers who don’t identify risks?
[00:06:06] David: We should never punish anybody, a punishment is not the right motivation in any kind of setting, whether it’s in professionally, or personally, or nationally, in society, we don’t want to be punishing people, we want to be encouraging people towards better behavior, so I think you should never be punished for identifying something that could go wrong in the future, if you also identify with it a course of action that you could take, so I would always if I was going to my boss, or going to a client, or going to my stakeholder or business owner and saying “I found this thing, I’m a bit concerned if it happens, then we could be in trouble, but don’t worry, because along with the risk that I’ve identified here is a potential risk response and some actions that if we take it would make this bad thing less likely or it would make it less severe and if we take these actions, in fact it might even stop it happening altogether”. So I think we shouldn’t be afraid of being punished if we go with a risk as long as we go with an action plan at the same time.
[00:07:12] Yegor: And how do we encourage project managers for doing that? For example, right now I’m working in a team of teams, so I have a number of project managers who report to me, and how do I encourage them to do this risk management, risk identification, because some of them are not doing that and that’s just that.
[00:07:28] David: Yes, exactly, I think there’s lots of things we can do as leaders, as managers. One is to model it, we need to be doing it ourselves, so at our own level of responsibility in the project or in the business we should be ourselves identifying risks, and communicating about them, and responding to them, and monitoring them, and then reporting our success at the end, and so there’s that kind of role modeling I think we need to mandate it, it needs to be part of our procedure and process, it just needs to be normal to identify risks, so of course you’re going to identify risks, you’re a professional engineer or a professional project manager, or project leader, it’s just part of what we do, so it’s just normal. And then I would also pull it, I would also ask for it, so when you report to me about your progress, don’t just tell me what you’ve done tell me, when we look to the future, what can you see that might affect our progress and what are you going to do about it in future. So I would expect to see it as part of our process, as part of our expectation of a professional engineer, or project person, and also to be role modeled by myself as the leader and amongst those sorts of things I would also celebrate success if we identify, you know, a big risk and then we deal with it. Well, let’s, you know, give somebody a pat on the back, or we’ll take them out for a drink, or we’ll do something to celebrate their success in managing risk, we’re not going to be punishing people for doing it wrong, we’re going to be encouraging people for doing it right, and then more people are going to want to be on that train, on that bandwagon that says it’s a good thing. I see that that the team leader is thanking people for identifying risks because a risk identified is a problem avoided, if you don’t identify the risk the danger is that you end up with a problem later down the track that you could have done something about, and that’s much worse.
[00:09:17] Yegor: Or missed opportunity. I’ve heard your video about positive risks or you’re calling them upside risks. So some people think that risks are something completely negative, and when I tell them sometimes that risk is just a line in the spreadsheet, it’s not something that you should avoid, it’s just the line with the different, like you explained in the video, it’s just with a different number in the impact column, and then they become opportunities that kind of surprises most of the people who I talked to.
[00:09:46] David: Yeah, I’m so glad you’ve mentioned that, I think that’s really really important and that’s another part of the motivation to identify risks, if we understand that there are two flavors of risk, two types of risk, there are bad risks and good risks, there are downside risks and upside risks, there are threats and there are opportunities, and this comes from the very nature of risk, the definition of risk that we have. So my simple definition of risk is just three words, I say that risk is uncertainty that matters. Other definitions, if you look in the ISO standard, ISO 31000, risk is the effect of uncertainty on objectives and objectives of the things that matter, so it’s the same thing. If you look at the PMI, the Project Management Institute - a risk is an uncertain event or condition that if it occurs has an effect on achievement of project objectives. But there are also, in those shorter definitions if you say risk is uncertainty that matters that doesn’t necessarily mean it’s a bad thing, an uncertainty that could harm us, that could waste time and cost extra money and damage performance and reputation, that’s an uncertainty that matters, because if it happens, it’s bad and we need to do something about it, but what about an uncertainty that if it were to happen, it would save time, and it would save money, and would help us to improve performance, or deliver more benefits, or enhance our reputation, that is also an uncertainty that matters, that we need to know about and identify and try and manage and so the idea of uncertainty that matters includes bad things and good things, and so does the idea of effective uncertainty on objectives, as the ISO standard says what kind of effect, well, a bad effect, but also what about a good effect, and so for the PMI definition, it adds those three words in it, says it’s an uncertain event or condition that if it occurs has a positive or negative effect on achievement of objectives, so I think that that changes the whole discussion, the whole debate, the whole thinking about risk. If you recognize that there are good risks that can save time, save money, enhance performance as well as bad risks that could waste time, waste money, and damage performance, and now when we’re identifying in our risk list, we have a list of bad things that might happen, that we’re going to try and make smaller or stop, but we’re also going to have a list of good things that might happen, that we’re going to try and enhance, or capture, and make sure that we get the benefits that they’re offering us, and then we go to the boss and we say “Here’s my risk list, actually, there’s two parts to it, there’s some bad things on my risk list, but don’t worry, because this is what we’re going to do to stop them or make them smaller, but also, Mr Boss, here are some things on my risk list which are good, which could help us to work faster, work smarter, work cheaper and here are my actions to capture them and make sure that we get the benefits”, and then that risk list is welcomed, because it’s a list of avoidable problems, but also benefits that we could capture plus the actions to stop the bad things and get the good things, and I think that way then it takes the fear and the negativity, the worry out of bringing risks to the boss, because we’re also bringing potentially good things at the same time.
[00:12:54] Yegor: Oh, that’s very interesting idea, so you’re suggesting that, you just said it, so we show them both sides and then they understand that we are not just being afraid of something and we show them the negative, yeah, we’re showing them the bow side, and actually that leads me to the next question. I wanted to ask you, do you think that this risk management is suitable for any manager and any team, or maybe we should suggest people to do this stuff only when they deal with managers more or less mature in their project management skill?
[00:13:27] David: No, I think risk management is a basic skill, it’s the most basic of all the things we can do as human beings, but also as engineers, or professionals, or managers, or business executives, the most important thing you have to do is survive, right? So you get up, you don’t poison yourself, you don’t go and cut yourself when you’re shaving and you bleed to death, you don’t cross the road with your eyes closed and you get knocked over, of course you’re managing risk all the time, it’s a basic life skill and nobody would survive if they couldn’t manage their risks, and so I think when we come to our professional environment in our projects and in our businesses, then the risks are there as well, and it will be stupid of us to go through our projects with our eyes closed and just trying to make the best of it. Of course we have to have our eyes wide open to see what’s in front of us, but also what’s coming down the track that could affect us, and I think that applies to small projects, to Agile projects, to big mega projects, to complex projects, it applies to small and medium-sized enterprises, to micro businesses, to charities, it applies to sports clubs and to, you know, community organizations, it applies to government departments and to nations, and to societies, right? From the very very smallest of me and my family - up to my nation and the community of nations. We all need to understand the risks that we face and do something about them, so I think it applies to every level of the human society.
[00:14:56] Yegor: You know, you mentioned Agile just now, and I have to say that in the Agile Manifesto which so many people quote these days, especially software engineers, there is not a single word “risk” in the Manifesto, so the Manifesto is written without any mentioning about risk management, and that kind of leads to conclusions which people make, the software engineers and managers, that risk management is something which is coming from PMI, like, an old school management, Waterfall, whatever and we are now doing Agile, so we don’t need this stuff anymore, we don’t need this risk list, and we don’t need this risk analysis quantitative, qualitative, doesn’t matter, it’s just all from the past.
[00:15:35] David: Yes, I mentioned it deliberately, I was being provocative, I thought you might pick up on that. So is it true that Agile projects don’t have risk, is that your experience?
[00:15:46] Yegor: No, no, definitely not.
[00:15:50] David: Of course they have risks, but I think that risk management has a specific role within Agile and it’s true that the first version of the Manifesto didn’t mention risk explicitly, but a lot of the things that you have to do in an Agile project are risk-based decisions, so for example when you’re putting together the functionality in your first sprint or your first tranche of work, your first element what we want to do is in order to de-risk the whole project, we put the most risky elements of functionality in the early tranches, in the early cycles, right, in the early sprint. How do you know which are the most risky elements? You have to do some kind of comparative risk assessment, right, so you go through your functions and you say this one’s easy, this one’s a bit tricky, this one’s really difficult, and so we do a very quick and dirty risk assessment of all of the functionality, all of the different elements, all of the parts of the user experience, or the user story and we want to put the most risky ones first, so we get those out of the way that means we need to understand which are the most risky, and then we put together a sprint or a tranche or whatever phrase you use depending on your methodology, we put together an element of work which says that in the next week or the next two weeks we’re going to create this functionality, we’re going to deliver this part of the work, and then we start work, of course, you have to manage the risk within that sprint in order to get to the end with the functionality that you promised, or that you expected, and so what we have to do is use risk management, when we’re creating the content of our sprint, and then we have to use risk management when we’re running the sprint in order to get to the end. Now the question is how do you do risk management in a in a five-day sprint or in a 10-day sprint, when we’ve got to have brainstorms and workshops, and risk lists and risk reports, and maybe do some simulation that we can’t fit all of that in to an Agile project where sprint is only five days long, right? So we have to do risk management in an Agile way as well, and for me that’s perfectly possible, because I reduce risk management to asking and answering six simple questions, and you can ask and answer these questions at lots of different levels of detail in an Agile project, you answer the six questions really fast in a megaproject, you take a lot of time and a lot of thought and energy in answering each of the questions, so I think in an Agile project, at the beginning of the sprint, you ask yourself these six questions. What am I trying to do? What might affect me? Which are the most important ones? What shall I do about it? When I’ve done that, did it work? and What’s next? and then you go back to the beginning, and you can answer those six questions in 20 minutes, in 30 minutes in your initial setup meeting, your stand-up meeting, at the beginning of the sprint, you can just say “Okay, okay guys, what have we got to do in this sprint?” - that’s objective setting, “What might affect us?” - that’s risk identification. “Which are the big ones?” - that’s prioritizing or assessing the risks, “What could we do?” - response planning, we do it, and “Did it work?” - risk review, and then “What’s changed?” - updates, or if you’re putting, you know, building a base station on the Moon, or you’re going to Mars, or you’re building a big new power plant in a city, then when you say “What are we trying to do?”, you spend a month on analyzing stakeholder needs, and defining objectives, and prioritizing them, when you ask the question, what might affect us, you spend two weeks in risk workshops with different levels of engineers and doing lots of different techniques which are the most important ones, you spend a week or a month building a risk model and analyzing the different risks, - it’s the same set of questions, but we’re asking them either really fast in an Agile project or really carefully in a megaproject, and so I think risk management does apply within Agile, it’s just that we do Agile risk management, and we do it in a much faster way.
[00:19:52] Yegor: Yeah, you just defined Agile risk management, it sounds really nice, I’ve never heard this before.
[00:19:56] David: It’s easy and it’s the same, you know, when I’m thinking about personal risk management, so you know I want to buy a new car, what am I trying to achieve, what are my objectives in the car, what might affect me, availability of the car, the availability of my finances, you know, all sorts, then which are the most important things and what can I do about them, and then I go and buy a car. I’m planning a holiday, my daughter’s getting married, all these things, I can apply the same six questions, I just answer them in a different way, so risk management is a very simple process, we apply it at different levels depending on the level of the risk challenge, so if I’m running a multinational organization like the WHO or the United Nations, then I have different questions, the same questions, but different levels of answer, than if I’m saying I want to take my family on a holiday, but risk is the same.
[00:20:47] Yegor: Do you think the Agile team has to write down the answers, or it’s just verbal?
[00:20:54] David: Yeah, that’s a difficult one. I think there is a value to documentation, but you know there’s documentation, and documentation I mean, you could write down, you know, lots and lots of detail, I think the reason for writing it down is twofold, one is accountability so that you can say “We said we would do this, did we do it?” and then the other is for education so we can come back afterwards and say “You know, my project is a little bit like this one, what risks did you have on your project, and how did you tackle those, and is there anything I can learn from that to help me? Now I’m on this project”. If you don’t write it down, then all of that previous information is up here which either gets forgotten or you’re not on the project, it’s not so easy to access, so writing things down is good for immediate accountability and longer term learning.
[00:21:45] Yegor: It’s interesting. Have you ever seen in your professional life as an Agile team with a written down risk list or some notes from the risk identification this session?
[00:21:55] David: Yes, absolutely yes. I mean I was the risk manager on an Agile program in South Africa for a big telecoms company, the telecoms company that sponsored the World Cup, if you remember back that far, so I won’t name them, but they’re a very big company in Africa. And they had a program to replace their entire billing system for not just the nation of South Africa, but all the nations that they worked for, and they decided to run this program in an Agile way, and I was called to support the programme team as a risk specialist and so we implemented Agile risk management within the Agile program and yes, we did write things down and we had risk reviews, but they were stand-up risk reviews, and they happened very quickly with the whole project team understanding what the issues we were deciding, what had to be done, going off to do it three days later, we come back, we have another meeting, “Did you do it? Did it work? What do we need to do now?” and there were minutes of the meeting, but it was all done in a very very fast and agile way, and the project was a great success.
[00:23:00] Yegor: It’s very interesting to hear this title risk specialist, this is again first time from you. Can you tell us a little bit more what exactly this role does in the project? I understand that we have a project manager and in my understanding this is the role who is responsible for all the risk identification and all risk approaches, but now you’re saying that you were invited specifically to be a risk specialist, not a project manager, did I guess right?
[00:23:24] David: That’s right, I did say that it was a big program to replace the entire billing system multinational across the whole of Southern Africa for this particular telecoms company, and so there was a fairly well developed project office and a program manager, and several project managers with different specialist roles, you know, planning and reporting and configuration control, and value, and finance, and risk, so that was the case for that project. Of course, it’s true that the project manager is responsible for managing the project, but that doesn’t mean that the project manager does everything themselves. So they have technical specialists, and then they might have administration specialists, they might have contract or finance specialists, and they might have a risk specialist. Now, the purpose of the risk specialist is to facilitate the risk process, to help the project manager to understand and manage their risks on their project. I have a little video, you might see on the YouTube channel, it’s called “Kill the risk manager”, and the idea of “Kill the risk manager” is not to go murdering people in your project team, but the idea is to say the term risk manager is really unhelpful, because it makes you think that the risk manager manages risk, which is the wrong idea, the project manager manages the project, but the risk manager helps the rest of the project team to understand and manage their risks, so I prefer the term “risk specialist”, a “risk coordinator”, “risk champion”, you know, there’s various different terms we might use, but “risk manager” is not a good term, because the risk manager doesn’t do the managing of risk and this comes back to the idea of risk being an uncertainty that matters, and uncertainty that matters, because it affects our objectives, so the person who owns the risk is the person who owns the objectives. Now, on a project team the project manager is responsible for delivering the objectives, so the project manager is also responsible for managing the risks to those objectives, but just like the project manager doesn’t do all the coding or testing themselves, or doesn’t necessarily do all of the earned value analysis - in the same way they don’t have to manage the risks themselves, they’re just responsible for making sure that it’s done, and on some teams that means you have a risk specialist, and on others it’s just delegated to the team. It depends on the size of the team and the way they’re organized.
[00:25:50] Yegor: And how exactly you were doing your job, you were talking to people, sitting together with them, building the risk list, what exactly was this specialist, this role you was doing?
[00:26:00] David: Yes, it’s not just with this project, this program, but generally speaking, the risk specialist job is to talk and listen, but it’s always to ask difficult questions, ask the next questions, so “What are you doing?”, that’s the first question, “Why are you doing that, why aren’t you doing this?”, “This sounds a bit stupid, have you not thought you could do it this way?” so you always ask a question and follow it with another question, and another question, so the risk specialist needs to be curious, but also knowing where they’re going to, so we’re drilling down into the details to find the uncertainties, to help people understand their own work. I don’t always understand what the project team are doing, I’m not a specialist in all the types of projects I’ve worked on, but I know how to ask people to expose the things that they’re uncertain about, and so of course a lot of that is talking and listening, sometimes it involves reading, a lot of the risks are documented in the contract or in the technical specification, or in the terms and conditions, the assumptions list, the constraints list, you know, sometimes we’ll find risks are hidden in the documentation, so a structured document review can expose risks, but most of the time it’s talking to people and creating those insights, so that they can express the things that they kind of know deep down, but they didn’t know that they knew.
[00:27:25] Yegor: And what was the output of your work, the risk list or instructions to people?
[00:27:30] David: No, the output of a risk person’s work is a successful project, so the risk list is irrelevant, the point of writing something down is so… I can tell you about it, so you can read the document and say is that what you did in that workshop or in that brainstorm? Now I see. But the purpose of risk list, the outcome of a risk list is understanding, and the outcome of understanding is action, and the outcome of action is success. So the only reason you do a risk workshop is not to create a risk list, it’s to document the new understanding you have. The workshop or the brainstorm creates understanding of risks and understanding of what you have to do, I call that awareness and action, those are the two key outputs, awareness and action, what do I know now that I didn’t know before, what must I do now that I wasn’t going to do before - those are the outputs and we might write it down in a risk list or a risk report, but the real output is not the report or the list, the real output is the awareness of the action.
[00:28:34] Yegor: Yeah, I’m just thinking how to measure the output, because the awareness is a good thing, but it’s hard to measure, let’s say, I want to hire such a risk specialist for some of my projects, so I will be managing the specialist I think that the project manager is managing the risk manager, risk specialist, and then the question is how do we measure the effectiveness of the work of this person? Of course we can say if the project is successful in the end. Then yes, everybody was a good player in the team, but down there, like, you know, more incrementally, how can we say that this risk specialist is actually doing his or her job correctly?
[00:29:11] David: Exactly. And it is a difficult challenge, because we’re talking about uncertainty, about things that might or might not happen, so I could write, I could identify a risk, you know, the roof could fall down and crush me, and so what I’ve done is I’ve closed the door and I’ve got a big piece of wood against the wall, you know, and I’m protecting something that is never going to happen, this is a waste of time to have the wood up against the ceiling and about the door shut, you know, it’s a stupid thing. It’s never going to happen. But I could also say that my computer could fail and this recording could, you know, cease to be made, so we have a backup for that and we will find a different way, so we need to manage the real risks and the question is how do you identify what are the real risks and not the kind of phantom risks, the pretend risks that don’t really exist? Well, it is a difficult challenge, but when we come to the end of the project and we look back over the project, we do our post project review or our lessons learned exercise. One of the things we should look at is the risk list, and we should say did we identify things that really could have happened, and if they were bad things we stopped them or we made them less bad, or if they were good things we captured them, and we gained the benefit. So you should find things where you identified it early in the project as a potential bad thing, you identified some actions, you took the actions and the bad thing didn’t happen, and we should be able to track those things through the lifetime of the project, or at the beginning of the project, we identified a potential good thing, and we changed our direction and strategy to capture the good thing, and we did capture it, and we got additional benefits, and we saved some time or saved some money, so when we come to the end of the project or at some interim lessons learned point, maybe at a gate review or a phase point, what we can do is look back and say “Well, did we spot the things that were coming and actually deal with them proactively?” and then we’ll know that we’re doing the right thing.
[00:31:12] Yegor: So basically you’re suggesting that we can measure the effectiveness of the risk specialist by the amount of opportunities we took and by the amount of threats we missed, right?
[00:31:27] David: That’s what I would say. Yes. So you identify a certain number of threats at the beginning and you can track how those are reduced with time, and you can identify a number of opportunities at the beginning and track how those are captured with time, and that can be quantified in terms of dollars, or rubles, or euros, or pounds, we can have a potential impact, a negative impact for threats which is avoided, and that’s cost saved, and we can also value the opportunities, and we can see how that value is captured with time, we could have a contingency pot, which we set aside to deal with threats and opportunities, and we can monitor what’s in our contingency fund and we can see how much of the contingency fund we spent on dealing with threats that we missed, and how much we were able to add back into the contingency fund from opportunities that we captured. So you can measure. There are risk metrics that we can use to actually see if the risk process is working effectively in our projects, yes.
[00:32:20] Yegor: What do you think, is it a hard job to be a risk specialist, or we can train, for example, a programmer who is now writing code and then we say “Do you want to be a risk specialist in this team or another team?” Is it possible to do an easy transition or a lot of education is required?
[00:32:36] David: There’s not a lot of education, but I think there are a whole range of different skills, some of them are technical skills, but more of them I think are personal skills. You have to be curious, you have to want to know what’s going on, you have to be looking into the detail, why is this, why are you doing that, you know, and actually being curious to find out, and I think the risk specialist needs to have skills at the high level, at the detailed level, so we must always remember the purpose of our project, the objectives, the people we’re serving, the stakeholders, the goal of the project, and at the same time be interested in specific parts of the project or people’s jobs which could influence that bigger purpose, and so we’ve got a high level, this is what it’s for, and the detail, this is what’s going on, and I think the ability to hold those two levels of detail at the same time is a key skill for a risk person. You have to have interpersonal skills, the ability to talk to anybody, to talk to the cleaner, or the security guard, to talk to the chief executive, or to talk to the customer, to talk to the project manager, or to the technical expert, and the ability to gain their confidence and trust, and to learn from them the things that are really concerning them. So there are interpersonal skills which I think you know are important. Some of those things can be trained and some of them are built in to the sorts of people we are, so I would be more interested if you were looking for a risk person to develop within your project team, I would be more interested in the sort of person they are, their kind of personality and character, more than the technical skills. Technical skills are easy to learn, you can learn interview skills, and brainstorming skills, and facilitation, you can learn about Monte Carlo analysis, you can learn about multi-attribute hierarchy analysis, these are techniques that are easy to learn, or SWOT analysis, all these things. What’s harder to learn is that kind of interpersonal thing, or that sense of curiosity and interest.
[00:34:36] Yegor: But I think that you’re saying that it’s better to take someone from the team, but I think that the risk doctor, the company you are promoting and you develop, as far as I understand, is more like a service provided to teams. Like for example my team where I don’t need to grow a person in my team, or to have a full-time person, but instead I can go somewhere, to some service provider and then ask “Can you please send me (like they did with you) a risk specialist, or send it to my project for half a year, for example, and let that person do all the risk management, not management, risk analysis, and then that person will go somewhere else”.
[00:35:19] David: Yes, and then they go and then you have no skills in your company, and then for your next project you have to hire somebody else, and that costs more money, and then you lose them, and then you bring another person. Yes, of course, you could do that, and obviously that’s my business, and that’s what the risk doctor partnership does. We are a risk consultancy, so some organizations build their own capability, their own capacity of risk management skills within project teams and within the organization, some organizations will have a part of the project office, that part of the project office service to the projects is to provide risk facilitators, or risk specialists, and for other projects it’s the right answer to bring somebody in from outside. So there’s a range of different ways of meeting the need, and I wouldn’t say that one is always the right thing to do, it does depend. So we tend to come in for projects that are big, that are complex, that are novel, that are innovative, where you need to learn from other industries, and so, for example, I was working with NASA on the the mission to Mars, and sending space astronauts off to Mars, and we had a particular technical problem in how to build a base station on the Moon, and they asked me to come and unlock this technical problem that they had in building a base station on the Moon. Now, I don’t know anything about building a base station on the Moon, but I do know how to ask the right sort of questions, so they can answer their own questions, they answer their own problem, and what I brought was a technique from pharmaceutical research and development, and actually how you develop new vaccines and something I had developed for a pharmaceutical company in Belgium, which they were working on, a particular problem with dengue fever, I think it was, and developed a risk technique, which helped them to solve their technical problem with a dengue fever vaccine, whatever that is. And I took that to NASA in Virginia, in America, I said try this technique on this base station problem, and it worked it unlocked the whole thinking it helped them to solve this particular problem using a technique that had been developed in the pharmaceutical sector. Now somebody, if they brought a NASA risk specialist, they would have been engineers, they would have been space specialists, they would have been, you know, in this world, but what we can bring as external consultants is a view of multiple worlds. You know, I’ve worked in nearly 60 countries, on every continent except the Antarctic. I’ve worked in 20 different industry sectors, and so I have a range of experience that I can bring, but it’s a little bit expensive, if you develop your own person, you know, effectively. They’re free, but they’re limited to knowing what you know what’s within your company. So, in England, we have a phrase “Horses for courses”, you know, you pick the solution depending on the challenge.
[00:38:10] Yegor: That’s true. I think that if the person stays within one team, within one project office, then the person will be a little bit biased on the risk they identified before. Exactly, yeah. That person will only know a few specific risk categories, and it will be very hard for that person to look aside from this, like you said, the box of view.
[00:38:35] David: Now yeah, so it’s good to move people around, even if they’re within the company and that’s why having the risk function within your project office is often helpful, because then they can look across a program of projects, a variety of different projects and take the learning from one project to another. So you know, there is value in the in-house risk specialist, but there’s also value sometimes in bringing in someone from outside.
[00:38:58] Yegor: Did you experience, in doing this risk specialist job, did you experience sometimes maybe some negativity from the on-site team? Because you were actually discovering problems for them, and I suspect that not everybody was happy with you doing that?
[00:39:15] David: Yes, yes, with this South African billing program, they had a risk specialist on the job, and he was very cross that they employed me, because he felt that it was showing that they didn’t trust him to do the job. Well, I wanted to help him, I wanted to make him look good, and serve him, and support him, and say “You’re the risk manager, you’re the corporate risk manager, I’m just some guy from outside who’s helping, I’m helping you”, but he saw it as a competition, and so he didn’t help me very much, and that created some difficulties within the team, and what we ended up having to do was to draw a line between a boundary for my risk work and his risk work, and then we communicated carefully across the boundary. So yeah, there was that kind of feeling threatened by an outside person coming in, and a lot of that is how, as the external consultant, how you present yourself, if you come in and you say, you know, “I’m the genius and I come in, you know, to rescue your project and rescue you don’t know what you’re doing, move over, let me do it for you” - of course you don’t win people, whereas if you come more humbly as a servant of the project to support them, then… and we need to work together, it’s their project, their objectives, it’s their risks, I’m just helping them find them and manage them more effectively. So I think yeah, you can threaten people if you don’t handle it well.
[00:40:47] Yegor: And what about the possible negativity between risk managers, you and your colleague who was on site, and people who were actually doing the job? Because in my understanding, when the risk specialists, risk managers start to identify risk, they somehow discover problems which people sometimes very often try to hide, so they may feel like you are a threat, so it’s better to get rid of you instead of getting rid of risks.
[00:41:12] David: Yes, yes, again that depends on how you present your purpose that the idea, the purpose for identifying risks is to deal with them, so most often you’ll find the team members, they know there’s something wrong, they know there’s something they’re worried about, that keeps them awake at night, or they’re desperately hoping it doesn’t go wrong on their project, and the reason they don’t want to uncover it is because they don’t know what to do about it, and so they hide it hoping it won’t happen. And what we want to do as risk specialists is come in and say “Look, let’s uncover it, so that we can look at it, so we can see it and then deal with it”, so analysis has to turn into action and if all we’re doing is exposing potential problems and saying “Oh, that’s nasty, well I hope that doesn’t happen”, and then we go good luck with that - that doesn’t help anybody, whereas if we expose the potential problem and say “Oh yeah, I’ve seen one of these before, why don’t we try this, this and this, and then that will protect you, that will make sure either it will never happen or it won’t be so bad”, and we give them practical ideas and then they’re grateful to you for giving them an action plan that will make their life easier, that will stop them worrying about these things, because we’ve exposed them and dealt with them, so I think if you come with that attitude of trying to help people, make their lives easier to help them get to their goals in the best possible way, then eventually they will welcome you. There’s always some suspicion, you’re right, but the other thing is if we remember to include opportunities and upside risks and we say, you know, as part of this process, “if you work with me, we’re going to find things that will help you work faster, smarter, cheaper, would you like that?” - “Of course I would, I want to save time, I want to save money, please, make my life easier, okay?” You engage with this risk process, we might find some problems where we have to kind of do this, but we might find some really good things, some nuggets of gold, which will help us to get to the goal more easily, and then people engage on that basis.
[00:43:13] Yegor: I like the word “eventually” you said here, so initially I think there is definitely a resentment from the team coming to these people trying to identify risk, I’m just thinking about my teams and how can I apply your advice to my practical work, and it seems that I should be prepared for initial resentment, this is the right word, which will be coming from the team, right?
[00:43:37] David: Yes. I think it’s all about how you present, so how you approach people, so I would always start with a five or ten minutes briefing that just explains to people what is risk, it’s uncertainty that matters, it matters to you, why does it matter to you? Because the bad risks will stop you doing what you need to do and the good risks will help you. Now I’m here to help you find the bad risks and the good risks, stop the bad ones and grab the good ones, and I’m here to make your life easier and we’ve got some simple techniques, we’re going to hold a workshop, we’re going to write a few things down, we’re going to go through some steps, but after a week you’re going to feel better, by the end of the project you’re going to be celebrating success that wasn’t possible without what we’re going to do together, and so in a five minute simple introduction to risk management, why are we here, what are we offering you, you immediately set the ground for something which is much more collaborative, which is much more positive. If you come in and say “Oh. You’re not doing a good job here and I’m going to find out why, and I’m going to tell the world about it” - of course, they won’t cooperate.
[00:44:43] Yegor: Yeah, that’s true. And let me move a little bit aside from the track of thoughts we have here. In the PMI books, in the training for the PMI I read, the PMP exam, I’ve read many times that they claim that for all the failures the project manager is responsible, so if something goes wrong with the project, no matter what, it is maybe a coronavirus epidemic situation, including that, the project manager is responsible, because if the project fails because of this situation, then it means that the project manager didn’t manage to identify the risk properly, and so on, and so forth. So do you agree with that?
[00:45:21] David: Well, I’m a PMI fellow and I did my PMP in the year 2000, and I remember that there are several kind of key answers. One of the answers is the project manager is responsible, so if you don’t know if that’s one of the options, then you always tick the project managers as possible, and another key answer is communicate with the project team. It doesn’t matter what you do, you have to communicate with the project team. And there’s key answers like that, and so, yes, the project manager is always responsible in PMI’s view. You have to recognize this is the Project Management Institute, and so the Project Management Institute will say that the project manager is important, or that the project manager is responsible. I’m also a fellow of the Institute of Risk Management, and the Institute of Risk Management says the risk manager is important, and the risk manager is responsible, so the Institute promotes its own area, and I say that as a PMI fellow, you know, I support PMI and I promote PMI and other associations, I’m a fellow of the UK Association for Project Management as well. So I’m not just a PMI person, but to the point, is it true that the project manager is responsible? Well, yes, but. The “but” is around delegation and leadership. So, as we talked about a little bit earlier on, of course the project manager is responsible and accountable for delivering the objectives of the project, and if the project fails, the project manager has to step up and take that responsibility, but it’s never one person’s responsibility. You know, a project is always delivered by a team, always, if it’s a single person, it won’t be a project, it’ll be an activity or a task, so we draw project management is about getting multiple resources, people together in order to work together on a shared task, so there will always be other people involved and somebody has to be the leader, and that means you. When the successes come, it means you get the pat on the back, but it means when the failures come, you get stood up, and you get told off. Now, the telling off should always include the lessons learned, what are we going to learn from this failure. Failure is a very strong word. I wrote a book called “The Failure Files” a little while ago, and the idea is to say that failure is completely natural, it’s part of the learning and growing process. In fact, failure is a positive thing, if we embrace it and use it in the right way. It’s a learning experience, and if we punish people for failure, then that’s the wrong response. What we need to do is to find out what happened and make sure it never happens again. So yes, the project manager is accountable and responsible, but that doesn’t necessarily mean, you know, they get punished. And I think we need to address that in a different way.
[00:48:14] Yegor: Yeah, I agree here, but my next concern is that if we go to the project manager who is not doing the risk management right now, then this project manager can always have an excuse that “something happened which is outside of my control”, and I hear it very often. Very often people tell you, like, “we’re doing our job, right? But there was something else which happened outside of my control, so I’m not accountable, so leave me alone”, and when you come to this person and say “from now on your responsibility is to actually think about risks, think about uncertainties, and now you are accountable for everything, for all possible negative and positive situations around your project” - then they may get a little bit resistant and say no. They may not like this idea because they become accountable for so many things and they will not be able to have an excuse in the future, for coronavirus, for example.
[00:49:06] David: Yes, well, first of all, risk management is part of professional project management, so we should always expect a professional project manager to do some level of risk management, and even if it’s taking those six questions and answering them in 20 minutes every Monday morning, there needs to be some approach to understanding and managing risk on the project, otherwise they’re not doing proper professional project management. Snd as I said earlier, you can do that at a number of different levels, so that’s the first thing. I would expect everybody to be looking at risk on their project, if they’re claiming to be a professional project manager, how they do that? Could vary, but the other thing is it’s never true to say “there’s nothing I can do”, never - you can always do something about every risk, including the risks that are outside your control, so the risks that you control, of course, you should be applying your resources to the high priority, high-risk elements, you should be managing your people well to make sure that people don’t get sick or stressed, to make sure that people are communicating, to make sure that information is flowing amongst the team, all those kinds of things. Of course you should be doing that and managing the risks that are within your control, but for risks that are outside your control, of course, you can do something. You know, it’s going to rain - that’s not in your control. If you want to go for a walk, it could rain. What are you going to do? You put on a coat, you put on a hat, you take an umbrella, you’re doing something to respond to an uncertainty that is outside your control. What you’re doing is protecting yourself. There’s a saying, you know, there’s no such thing as bad weather, only inappropriate clothing. So for you, in Moscow it’s really really cold, you don’t go outside in shorts and a T-shirt, you go outside in the fur hat, and the big thick coat, and the gloves, so you’re appropriately managing the risk of catching a chill, for something that you can’t control. So the same is true for project management. There are things that are outside our control, but if we see them, we can protect ourselves, we can prepare ourselves, so a supplier may change their price, or a supplier, a key component may not be available, or a competitor may enter the market with a different strategy, or somebody may go sick on my project - all these things are outside of my control, but I can be prepared for them in advance. I can have contingency plans, I can have backup plans, I can have alternative options, so that if the thing happens, this is what I’m going to do. If it rains, I have my umbrella, I put the umbrella up. If I think it might snow, I already wear the hat and the gloves, so we’re doing things in advance to protect ourselves from the things that are outside of our control. So it is never true to say “there was nothing I could do”. You always have a contingency plan, you always have a contingency budget, you always have backup options, and if you don’t - then you’re not being a professional project manager, in my opinion. That’s a bit strong isn’t it? I bet you’re glad I’m not your boss.
[00:52:11] Yegor: Well, actually it’s not really strong for me, I totally support this, I’m just thinking how we can apply these ideas to situations, to teams which are not doing this at all. Remember my first question, how we started? The real story, the majority of people in the industry, we’re talking about small and mid-sized projects, not NASA projects, but people don’t really know what is risk or list, so nobody tells them what is written, they’re just sitting right now in front of YouTube watching all this and thinking “well we go tomorrow to the office, so what should I do? How do I start?”, and I’m thinking that in most cases they will fail initially, so they will definitely have problems in the beginning, when they started, and one of the problems which I would like to address right now potentially for these new people is that they may start doing this risk management, they may start bothering people with the question, let’s call it, you know, what’s going to happen - they will approach people who they never asked these questions before, so it’s going to be a surprise for programmers sitting and doing something, and then they show up and say “you know what, I was listening to the podcast yesterday, so now we’re going to do risk management, so tell me about the risk”. They may tell them something, but they will expect some return to like some benefit from that. So, okay, I tell you about this risk, it’s funny, it’s interesting, and then what happens next? So how do we return something back to the team so the team knows what was that about and what’s the value for the team?
[00:53:34] David: Yeah, well, and this is where, and I think I mentioned this earlier, turning analysis into action, so what I would say if I was the project manager is, if you tell me of something that you are worried about, which could affect the success of the project - I promise you that we will do something about it. If you tell me about something you’re excited about, that could help us deliver the project better - I promise you we will do something about it. Now, doing something doesn’t mean I give you a million dollars and I give you a promotion and, you know, becomes the most important thing. Doing something might mean we just will think about that and be prepared, or it might mean there’s a whole range of different actions that are possible, but I think if we’re asking people to expose their concerns to us, their worries, there has to be something for them, the point of this is to make their life easier so they’ll have fewer problems, so they’ll have more benefits, so they will get to the project at the end with less trouble and with more success. And so that’s what the promise is, that’s what risk management offers. And if we’re going as project leaders or project managers, trying to engage our team and saying we haven’t done this before, what I want you to do is to tell me about the threats and opportunities, the uncertainties that you’re grappling with the bad ones that worry you, and the good ones that make you a little bit interested and excited. There has to be something that follows, and there’s something that follows if you tell me, I promise that together we’ll do something about it, which means we’ll stop bad things happening and we’ll make good things happen, and at the end of the day our project will be more successful, and without that promise, then I think you’re right, we’re asking people to give away knowledge and information, to expose their concerns and their worries with nothing in return, and then why would they…
[00:55:27] Yegor: Yeah, and maybe we should be careful with the promises, because if we approach them with a strong promise that “now you tell me all the worries you have and all the concerns, and then I promise you that something will be done”, and maybe in the next few weeks we cut back to them and they say “so did you do something with this, this and that?” Nothing. Not because we couldn’t try, but because you know situation, we need time, and so on and forth, so the team may get frustrated.
[00:55:52] David: Yes, so we have to work together with the team when we say something will be done, so the risk process has objective setting identification assessment, and then response planning, and in response planning, you know we’re going to do something we should involve the team together. So, you told me about this potential problem, you obviously understand it. What do you think we should do? Well, I think what we should do is delay this activity until this one’s happened, or I think we need to get some help from outside the project with this specialist skill, or I think whatever they think we need to develop together because ownership is really important. That idea, not risk ownership, but just kind of identifying with the problem and with the solution, and if you engage people in developing the solution together, then they’ll be more inclined to own what’s going on and to see it as part of of their project rather than something that’s imposed from outside, so you tell me what your worry is your concern, then together within the team we’ll work together to agree an action plan. That’s appropriate. That’s affordable. That’s actionable that we can do something about and then we’ll do it.
[00:57:01] Yegor: Do you think the risk list should be published and available for all members of the team?
[00:57:06] David: Yes, I do. I think if it’s our project, we need to know what we’re up against. Information is power and to know what the risks are, and the associated actions, the top risks, they should be prioritized, the ones that are most likely and have the biggest impact that we’re really concerned about, these are the ones we’re focused on and we want everybody to know, this is why we’re going in this direction, this is why we’re prioritizing these particular tasks or this part of the project, this is why we’re spending money on researching this particular area so we all understand. And I think otherwise if you hide information, then you get rumors, you get all sorts of half stories about what’s going on, I think there’s nothing to be afraid of with risk, it’s part of the information describing the project, we’re all in this together, the whole project team wants the project to succeed, and the risk list is part of the story. It’s like it’s part of the progress report, this is where we stand, we’ve spent this much money, we’ve spent this much time, we’ve created this functionality, and this is what we’re facing in the future, here are our threats and our opportunities, and together we’ve got this much money and time left, we’ve got this much this much functionality to create, and we’ve got to overcome these risks. So together we understand what the challenge is, and then we can engage and get there.
[00:58:23] Yegor: It seems to me like a risk welcoming culture, I would put it this way, and to move to that culture from the position where we are now, most of the team. It may take time, don’t you think?
[00:58:36] David: Yes, developing, maturing culture or reshaping, reforming culture does take time and the academic research says maybe two years to change a culture in an organization. I think in a project team it might be quicker, because we’re a smaller team, we’re more focused, we work together on a day-to-day basis, so the whole organization might take two years to move slowly along, but in a project team, we can develop the culture perhaps more quickly, but it is a challenge, we’re trying to change the way people think, and so I’ve done some work recently on defining the risk mindset, the way of thinking about risk that shapes the right risk culture, so things like recognizing that risk is completely natural. Now, there’s risk outside, there in the big wide world, whether we talked about, you know, Covid, the pandemic, well there’s all sorts of areas of uncertainty, it’s quite natural, it’s quite normal, there’s nothing to be afraid of, some of the risk is good, not all risk is bad, and risk affects the things that matter, and so we need to do something about it, and the basic mindset that says risk is nothing to fear, risk is just part of life, and if we understand it, we can do something about it, some risks we can directly tackle, and others we have to just prepare for and protect ourselves, but there’s never nothing we can do, there’s always something we can do, so let’s do it, and if we do it - it makes our lives easier. Once you get that way of thinking, then it develops that culture that says “well, if this is going to make my life easier, of course I want to do it, why would I not identify and manage risks if it helps me achieve my goals, my personal goals, my project goals, my business and life goals? Of course I’m going to want to know the things that could affect me, which are the big ones, and what I’m going to do about it?” And so, this process, this very simple management, risk management process helps us in all aspects of life: projects, programs, business and so on, why wouldn’t you do it? But it starts with the way of thinking.
[01:00:44] Yegor: Yeah, makes a lot of sense. So let me finish with the last question, because we’re running for an hour or more. Yeah. It was an interesting conversation actually because…
[01:00:54] David: I’ve enjoyed it, too.
[01:00:56] Yegor: You’re coming from a real practical experience with a large organization. We are more in smaller groups and smaller software groups, where as I told you before most people don’t know anything about risk management. So, what kind of books what books exactly, maybe what software, maybe what website you would recommend our listeners to read in order to understand the problem better and to learn more about this?
[01:01:24] David: Okay, well, first let me say I don’t only come from that big organizational background, so a lot of the things that I’ve done are with small projects, with charities, with religious groups, with churches, with groups of village elders in Africa, you know, various micro projects as well. I’ve mentioned NASA and those other things because they’re nice to mention. Everybody knows about them, so all of the things I’ve talked about work on micro projects, as much as they work on mega projects, so this is not a big project, small project thing… It would sound a little bit selfish to point people to my YouTube channel, wouldn’t it?
[01:02:03] Yegor: No, no, no, [indistinctive voice] so definitely, I will give link to everybody
[01:02:09] David: Okay, so one word, Risk Doctor video YouTube channel, there’s a playlist called “100 Risk Questions”, it’s a hundred videos, each one is about five minutes, maybe five to seven minutes long, it addresses all sorts of different questions about risk management starting with the most basic, so the first ten videos are the basics, what is risk, why does risk management matter, how do you manage risk, you know, the very basic simple things. And then the next 20 videos are about the process, how do you identify risk, how do you assess them, is quantitative analysis important, what response options are available, how do you choose a good one, so the first set of questions of videos in the question playlist are really basic, and you can start with those. If you know nothing, start at number one, if you’ve got a little bit of detail, start at number 11. If you’re an expert, you start at number 70 and then you do the last 20 or 30 which are really interesting, about artificial intelligence, and about risk, and religion, and about, you know, gender, women and men, and how we think differently about risk. Now, there’s some really interesting stuff down the back end of the “100 Risk Questions”, but the basics, the sort of, videos 1 to 20 are a good place to start. I would look at what PMI says about risk, I think the PMI PMBOK guide risk chapter has a good summary of a risk process, and some good tools and techniques, but I think there’s in terms of books, again, I’ve written 12 books, some of them are very simple, some are more complex, but I think nowadays I would start with a video, and the YouTube channel that I have has lots of great stuff and that will be a good place to start.
[01:03:55] Yegor: The last question: do you recommend people to get the PMP certificate?
[01:04:01] David: The PMP certificate? Well, who are “people”? I don’t recommend my wife to get it, or the postman, but if you’re a professional project manager, how does anybody know that you’re any good, what certification can you have, that will demonstrate that you have a recognized standard of project management? There are several project management certifications available, PMI is the biggest global project management organization in the world, and the PMP is the most recognized project management certification, so I would say if you’re a professional project manager, then you have the project management professional certification, the PMP, it kind of goes with the territory, but you need to recognize it’s a certification, so it certifies you as being able to do something, you have to be able to do that thing first and then you’re certified. So, gaining the PMP certification doesn’t give you anything, it just tells people what you’ve already got, and so if you’ve got it, if you are a professional, then get the badge and tell other people. I would recommend it.
[01:05:09] Yegor: All right, thank you very much, that’s a really nice recommendation. Thanks for attending the Shift-M podcast, it was really interesting and important for us, and I hope maybe I will see you sometime later again. Thank you.
[01:05:24] David: Let’s do this again, I’ve enjoyed it. Thanks very much, Yegor. I appreciate that. Bye-bye.
[01:05:28] Yegor: Bye.
