Transcript for:
Essentials of Risk Management in Projects

So just the contents we'll basically cover today. So I'm going to go through you guys with the risk management overview. After that, so you guys can't see this now properly. Is that better? Sorry guys.

So I'm going to give you guys an overview of what risk management is about. Why do we have project risk managers? Why do we actually have a specialised field only looking at risk management and what we do?

And what value... and contribution we can actually make, how that feeds into ISO 31000, PMBOK, which is your PMP for any project managers around you. Then we'll go into a case study, so kind of lessons learned. I'm going to use one of the projects that's actually to date, it's one of the projects that's gone horribly wrong on time and money.

It's still recorded as one of the worst projects ever done to date. Then we'll go back to basics with risk management process. So what is a real risk?

When isn't a risk really a risk? When is it actually a cause? When is it a consequence?

Because it's very important to make the distinction between. because your costing depends on it, your scheduling depends on it, your company's strategy and decision depends on it. So we need to make sure that when we identify risks, it's actually real risks. So we'll go through that, what's the definition, then we'll look at quantitative risk analysis. So basically QRA consists out of two things.

We've got QCRA, which is quantitative cost risk analysis, which I say we usually build a Monte Carlo simulation in AtRisk, which is a Palisade software tool. and then we've got QSRA, which is Quantitative Schedule Risk Analysis, and we usually do that in a primavera risk analysis, so mainly using P6 schedules, though we can also do a schedule risk analysis using Microsoft Projects. We'll just convert the Microsoft Projects program into P6, import it, and do a risk learning from there, which I'll go into more detail, and then just some final thoughts on the day we'll cover with you guys.

So just with regards to... an overview about risk management. So if you go and look, and I don't know if any of you are familiar with ISO 31000. So ISO 31000 is basically, it's the principles and the guidelines to risk management. So a lot of people always know what ISO 9001 is and what it stands for and its quality, et cetera.

But not a lot of people will know that risk management actually has its own standard, and it's called ISO 31000. And I would really suggest that if you guys are in a position to gain a copy of ISO 31000, thousand that if you guys can get a copy it's it's very valuable it's something you can always refer back to it's a good reference point if you guys get stuck somewhere in a risk management process that guideline will definitely give you the answers to what you're looking for then with regards to what does ISO 31 thousand say what do they say what's the definition of a risk so basically they say it's the effect of uncertainty on objectives so of course you'll have an objective in mind and you'll say for example it would link probably to your company strategy so part of the strategy would maybe be we need to invest X amount of money in a new project, the project is going to take us about five years and the objective of that would be because the business is growing, more capitalization it might be something the country needs if we look at a Madupi or a Kaseeli power station so it's more to do with the infrastructure and the requirements for our economy itself. So it is that what will the effect be of uncertain things that we face in life every day on those objectives? So what would pose a risk to us meeting those objectives?

And then as well, the effect can either be positive or negative deviation from your objective. So not all risks are bad. People usually think if you stay at risk, they just see red lights and they think, oh, we're in trouble, etc. But actually the true definition of risk, it's either positive or it's negative. And it's actually known as it's either opportunity or it's a threat.

So an opportunity, of course, leans toward a positive event, where a threat leans towards a negative event. And what happens there is that if we would assess risk, so risk consists of opportunity and threat, then what we would do is we would try to increase the likelihood and the consequence. of an opportunity. So a lot of people say but there's not really a lot of opportunities. or show me how do I identify an opportunity in a project for example.

Now if we would refer to a construction project, so let's say we're in a construction phase already, we've mobilized on site and we need to procure material. So management makes a decision in the opportunity to say well apparently as the economists of the country say that there will be inflation next year so we decide to procure bulk material now we should know know the consequences and the risk we face, so we need to make sure we have a storage facility, preservation is done, etc. But the procurement of bulk material will probably save us, and we can do the calculation, let's say it will save us 30 million rand worth of expenditure on material.

So the opportunity in that is that there could be a cost saving to the project. So what we would do is we will say, well, what's the likelihood of us being able to procure this material this year and not next year? In order to hack into that opportunity of the cost saving of a few million, then we'll say well it's very likely we can get the orders out, place the orders, we can have it on site before the end of the year, have the invoices paid and the consequence of that is that we've had a 30 or 40 million rand saving on bulk material. So we tend to miss opportunities and projects and there's actually quite a few opportunities that we can explore and that we can actually...

tap into and make sure that we do get that cost saving. But then on the other side again, then there's a lot of threats that we need to establish what's the likelihood of that happening and then what would the consequence be. Now the consequence can be quite a few things.

It can have a financial impact, it can have a delay in schedule on the project, which will in turn probably also mean financial impact because time is money. With downtime standing time... whatever we assess on site and then as well as a consequence could be we could have an injury or a fatality on site if we lean more towards safety point of view from a project point of view so if you guys can just keep the objectives of risk management in mind as we as risk managers we don't just look at the negative and the threats on projects etc we also explore the opportunities within it and and and what could the benefit be then we have risk and opportunity management so basically risk is seen in this sense as let's say call it a threat and then the opportunity as we just discussed so with regards to overall risk and opportunity management and the process it will be applicable throughout the entire organization or of course the organization would have various levels so if we would for example start at the top so we always have corporate and strategic and these decisions are made looking from a business strategy point of view So what's good for the business and what will make the business grow, what will be financially beneficial to the business. So those usually happen at the top from a corporate strategic point of view. Then in the next level, we have the program level.

So that's when we decide to action the strategy. So we've got a strategy in mind. We know which way we're going to go. So we've got this picture all sketched, but now we need to go over into a program level.

and we need to say, well, how are we going to put the strategy in action? Where are we going to start? How are we going to start it? And then the next level is basically the project, where I like to specialise in, and that is implementation of those actions, actually going over. So we've appointed a contractor, mobilising on site, we've got the budget, we've got a baseline schedule, and now we can actually start with the project in itself.

And then, of course, after that we've got operational. So whatever we've built... we've commissioned it and now we can just operate and then it will of course roll back to the top of which capitalization will happen and hopefully that would start showing profit which will then in turn roll back up into your corporate strategic side so like you can see the arrows they keep on moving in a circle so even though we haven't commissioned the project yet and we may be still in a construction later on the project level phase the risks we face on a project level we will deal with those risks risk as much as we can on a project level but a lot of that would probably pose a threat to your strategic risks or to to the company those are the type of risks we were all up to corporate and strategic so for example if something drastically on the project is posing a threat to what the company had in mind strategically and let's say it will be a huge impact like the project might be delayed for two years means two years worth of investment we're paying interest on that and And for two years...

We won't be able to capitalise it when we thought we were going to. And what impact does it have on business? Cash flow. Like they say, cash is king.

So it basically rolls back up into corporate strategic, going to tell the board members we are facing X, Y and Z, just so that everybody's aware. So it has this continuous circle of moving through the business on all those levels from a risk point of view. Then you've got a project life cycle.

So in the first phase we say well we identify for example a need, we need to build APSA, Barclays need to build let's say five more branches in the country. for better service providing, maybe a town has expanded. Like if we look at Medupi at Alice Rust, I mean, that was a small community. And I mean, within the last five to six years, it's basically just boomed with infrastructure.

there's a need for more for another bank maybe APSA in Alice Rust so they identify the need then they go over and there's a selection pre-feasibility phase they need to go and look at that of course rolls over into doing a feasibility on the strategy and once they've decided which way they want to go and then of course the final one of actually implementing that in itself so basically what the risk exposure and the information shows you so basically what it will say is you We will do qualitative risk analysis and it will kind of roll over into quant. So, yes, we can do quantitative risk assessment at a pre-feasibility stage and at an estimating stage, but because the information we have at our disposal is quite little, because now we don't have quite the design in mind yet, we're not quite sure what budget we want to spend, we're not quite sure what timeline we want to have it done by, because the information is very little. it's very difficult to always do a quantitative. So we do qualitative, we identify just the risks without any monetary value on it, and just say, well, these are the risks we face.

And then you will see as we progress through the life cycle of the project, that is beer definitely after this. There's a penalty, I think. Okay, so with little information, of course your risk exposure is very high.

The more the information becomes available or to our disposal, the less the risk would be. In the sense that it's not to say that the risk impact won't be major on your project. It's just saying that the more info we have, the better we get at being able to assess the risk, to cost them, and in order to put any treatment or mitigations in place to try and either prevent them or try and reduce the impact.

So if they do occur... that we won't take the full risk to books, for example, on cost or schedule. So we try and mitigate it down as well, because not all risks we can fully mitigate.

So we try and put as many treatments and mitigations in place to try and lessen the blow, if we can put it that way. So that's basically your project life cycle. Then with regards to a case study, so there were quite a few case studies we could look at, but I thought a very interesting one that we can refer through the entire masterclass is with regards to the Sydney Opera House.

I don't know if anybody really knows what the history is around the Sydney Opera House, but basically what happened was that the New South Wales State, which is one of the states in Australia, they decided, well, they saw this need from the music consortium that they need to build an opera house. So what they wanted to do is basically they wanted... hall that had opera and they wanted a hall that would have symphony concerts.

So they basically wanted a multi-purpose opera house, so it's basically a two-in-one. So they identified the need in 1957. But the way they went about tendering it was a bit abnormal. It's not really how we would tend to do business.

So what they did is they kind of put it out as a competition to the market in Australia. And they said, kind of this is what we have in mind. And they wanted architects to enter the competition. Basically saying how the design would look, how they would picture the Sydney Opera House looking. They received about 233 entries, of which a guy from Denmark, John Utzon, out of all the entries, he won.

They liked his concept and his idea the best, and they actually appointed him. as the architect. At that time Cahill was the premier in Australia and with strong opposition from his fellow members, they kind of criticized the project.

They said firstly it wasn't done 100% right, that's not really how we be, we don't do it through competitions and what was the assessment criteria you used to decide which architect you were going to use for example and basically because he was getting so much pushback from the other members he basically made that his pet project he thought well all eyes on me big stress now so now I need to to run this now I've never really heard of a premier or a president of a country actually taking a project under his arm and just running with it because they don't really have time to do those type of things. Nowhere do they really make mention if he made use of an EPCM or an owner's team. So he kind of tried to run this project on his own, do the interfacing with the architects. They actually appointed Arab as the engineers back in the day and just tried to prove everybody wrong that he could fly this project.

Now that we must understand is a risk in itself, is when you don't think you need help or if you think that you understand construction but it's not really your forte or your environment. So it's very important to always have that project team that will consult you, that will advise you. So this guy just decided to run with this project on his own.

Then they said, well, they were aiming to open the Sydney Opera House and have it done by January 1963, and it will have a total cost of $7 million Australian dollars. Now, when they went out to market with this... competition saying they needed architects to enter. They never really gave the architects like a design or concept that they had in mind. All they told them is it must be a multi-purpose opera house.

That's all they said. And they never spoke to any costs. So they didn't tell any architect, look, if you enter, you can have all the great ideas in the world, however you kept it X amount.

So it was kind of an open checkbook. And these guys, of course, could design anything that they felt like designing because there was no budget. Then after they've appointed the architect, they put a date to it.

And then they said, well, it's only 7 million Australian dollars, which in 1963 was quite a lot of money. Then what happened is, in all of this design, engineering phase, mobilizing on site and construction starting of the Sydney Opera House, the Premier actually, Cahill, he actually felt very ill. The other risk that he exposed himself to is when he felt very ill, he never asked people again for help. He was still trying to run it on the sideline. Now, we all know in a project environment, things change on a daily basis.

So even if you... sick for two or three days it has a huge impact decisions are made contractors commercial a lot of things happen in a day still this guy didn't ask for any help he was going to try and fly this project on his own so by March 1959 the construction begins before plans are finalized. Now I have to say in the last eight years working on construction projects, I've never worked on a project in the country or in Africa that had more than a 30% model review done from an engineering point of view, which is quite a huge risk. Because and sometimes it's very simple or the easiest way for me to explain it to people is basically saying well If you had to draw me a picture Let's for example use this one you can choose which 30% you want to draw of it So you can draw little pieces. Yeah, we can just draw the 30% of the picture Yeah, etc or however you want to engineer it so at 30% model review these guys usually feel from engineering and the and the client and the contractor site that They need to get this project up and running they usually already behind on time and budget is already under pressure and it's being constrained.

And of course there's a lot of pressure from the company, from corporate and strategy saying guys are taking longer than what you stated so we've got to fly this job. 30% model review is done, first engineering drawings are issued and of course the contractor will start procuring and they'll start the construction on site. The problem is by the time they get to a 70% model review They go, well, actually, if we want to do this, then we've got to change something that we've started already.

And it happens time and time again on construction, that when the engineering starts changing... start issuing revisions, red lines are being done in the field, the amount of buggeration it causes within a project construction environment is actually to a point sometimes devastating. It has your compensation events so it will cost you time or cost you money of which the contractor will probably be liable to and we actually then we've started the project wrong in that sense and that's one of the things the Sydney Opera House did as well. They started construction before the plans were finalised. analyzer before they saw the entire picture of what the sitting opera house should look like.

So basically in 1961, only two years, after they've started, the project was already behind with 47 weeks. So in two years, you've lost a year, basically, but more than a year, which is quite shocking statistics if you think that they have overrun on schedule basically with 100% already. And there was various reasons. It wasn't just only assigned to design and not being finalized. So they had a lot of inclement weather.

They didn't know how to deal with some of the stormwater drain, which says that from a project risk point of view is... is did they really do a proper risk assessment and a risk register before they started this project, saying, well, is it a greenfield site, is it a brownfield site? What's the weather in tropical monsoon weather? Does it rain a lot?

Is it very hot there certain time of the year? Did they do a proper site location assessment? Not a lot of people do that.

Not a lot of people think it can be done. But what they do tend to do is they can ask project managers, risk managers and we do go out to site because sometimes in Africa if it's a very remote location there are various risks you face as well now of course the client will stick to its guns and you'll say well I want to build it there come out of high water but we just need to know that what we face while we in construction and operation phase but unfortunately they don't always involve us at that point in time they usually get us involved when the schedules already two years behind and the budget's gone out the window and they have no contingency left, then usually they call in the risk manager and they say, well, tell us what we're doing wrong and where we're going wrong. And that's kind of part of the sad story.

So they couldn't identify this because a proper risk assessment wasn't done about in Sydney, the location where they wanted to build the opera house, etc. So they faced quite a few obstacles and constraints in starting and continuing with the construction of the opera house. opera house.

Then in 1962 there was controversy so you had your architect and you had your engineer and then all of a sudden they say the cells which is the roof which is quite magnificent today it had to change. And the reason behind that was that it was for structural reasons, it wasn't going to be fit for purpose, it wasn't going to be safe for use, so we needed to change the sails from a structural point of view. It actually took them... So after five years, they come up with all of a sudden, we need to change the sails, the roof needs to look different, etc.

After that, it took them another three years to actually design the roof. So it took them eight years just to design, detail the sails, the roof in itself, which poses a question that these guys maybe really know what they were doing. Then in 1963, construction of the roof started.

Then, of course, in the press in Australia, the Opera House becomes a joke. Cahill is under more pressure than ever. The Premier saying he doesn't know what he's doing. He's overspending.

He's overrunning. It's the worst project ever done in Australia, they stated, and currently, unfortunately, one of the worst done in the world. And it just became a national and an international joke. Then they decided in 1964 that they were going to demobilize and cancel the contract they had with the architect.

They said, well you've basically designed it for the last seven to eight years, you won the competition, but Mr. Architect will know. longer require your services and we will bring in four new architects the panel of four Australian architects were brought in now I've worked on two projects recently where they actually changed the engineering house halfway through construction which I don't think if we think of doing it and I understand the frustration sometimes From a contractor client point of view with the engineer is that if there's a lot of revisions, there's a lot of buggeration on site, it's hampering progress, it's hampering the construction or whatever we need to build. But sometimes they make a decision and they say, okay, don't want to make use of this engineer, he's been here for three, four years and we want to bring in a new engineer. Now, let's just think about that for a second.

So firstly, the risk we now face is that we will not be able to hold that engineer liable anymore. Because as soon as another engineer touches his engineering or his design, he's going to say... Well, if it fails in a few years, I'm not going to take responsibility because I don't know what the new engineer did. And it's a fair statement. Because if I would start building a house and all that needs is the roof and the chimney...

they say well we don't want you to continue building the house we're going to get somebody else and then for some reason five years down the line that structure of that house fails and they come back to me I'm going to say but I'm not the last guy who worked on your house so I don't know when they put on the roof if they've put the walls or the integrity of the walls at risk so I'm not going to take liability the same thing if you replace engineers on a project is you can't hold the first engineer liable or accountable for anything then there after that becomes the new engineer. Now a lot of people will of course debate and argue about that saying well the design engineer needs to sign off on it, they need to stay liable etc. But I can't really see any engineering house just saying well okay you're chucking us off the job, it's fine, we'll come back in five years time when you've finished constructing your project and then we'll sign off as the design engineer. It's not that simple, it's not that easy and they won't always agree to that because they are exposing themselves to a whole lot of risks then as well.

So they change the engineers, of course the new engineers, architects, they would want to do a validation. They want to say well what does all the plans look like, what's been issued, to what have we constructed, they'll do their own little validation and then only will they carry on. Now they say this validation depends on the size of the project, usually takes 4 to 12 months. So you can just smack that onto your schedule because that engineer probably won't continue issuing any drawings unless he's done his validation, he feels comfortable with where they're at and where he needs to continue from.

So they brought in four new architects. And they said, well, we want you to finish this job for us. In 1967, they make major interior design changes.

Major ones. So architects came in and said, well, we're cash-strapped. We've overshot the delivery date already, because in 1967, they were supposed to have been done by then, in January.

And they say, well... We are going to change the interior. It's not going to serve the purpose for what it was initially intended.

So it was supposed to be a multi-purpose opera and concert hall and now it's just become solely a concert hall. So no opera, just a concert hall. So firstly they've overrun on money, they've overrun on schedule and now they have to go back. ...to the Australian population and say, well, we're also not going to give you what we initially promised we were going to give you.

We're going to give you less. We're going to drop the standard just in order to finish it. At that stage, they had to write off about $5 million.

Australian dollars worth of machinery, which was redundant then. They weren't going to use it, they've procured it, and now they physically just have to write that cost off. Now from a risk point of view in corporate, that means it is...

imprudent spending it's wasteful expenditure now from a corporate governance point of view it's not that easy to let it go so if I can kindly refer to quickly to king three if you guys want to make a note if you want to go and read up on king three it's very important what king three says king three says that if you either trade on the JSE or you work with taxpayers money or you work with investors money you will prove that you do apply risk management. You will prove that you do have the interest of your shareholders at heart and that you are managing and mitigating any risk that they might face from investing into your project or into whatever project or initiative you have and you needed money for that to fund it. In King 3...

It will also tell you that you need to comply to corporate governance, which means if you would write off something like $5 million worth of machinery, it was wasteful expenditure, you will have to prove why did you just write it off. because not any investor or bank is going to say well okay five million down the drain what they usually do is they usually could back charge that that business or that company and say well we're not going to pay for it goes back onto your bottom line whatever profit you make for this this year if you make any you are going to give us that five million dollars back because we are not going to take that knock of the money. So it's very important if you guys can go and study up on KING3 and what it says, especially around corporate governance and what we are compelled to do from a risk management point of view. So risk management is not always just on projects or insurance or banking.

We are actually legally bound to certain things. that we need to deliver and that we need to ensure that we adhere to. Then as well the whole seating design in the interior of the hall changed so it was totally scrapped and it was changed to a lower standard saying well we know what it was initially intended for but for project saving and timing we're just going to downgrade a lot of the things. So basically what it boiled down to, so the Sydney Opera House, it took them in total 14 years to complete the Sydney Opera House. And they went from a $7 million Australian dollar to $102 million expenditure.

So I mean, it's a thousand times that they've overspent plus on what their initial budget was. which is a lot of money if you take that they still don't have to this date. The Sydney Opera House is still not a multi-purpose concert hall like they intended it to be. It still doesn't have the interior they pictured it to have.

it's still not designed than what they initially had the idea when they started construction in 1963. Then in 2002 they actually tried to, they are actually still trying to get the Sydney Opera House to the original idea that they have to make it look like the first picture they had back in the day and to serve the purpose the multi purpose they wanted it to serve so they actually went and they invested over and above the hundred and two another 45 million Australian dollars to start trying to get it to what it should look like so even with the investment of 45 million they still don't have the Sydney Opera House to what it was initially designed for and intended So let's look at what were the lessons learned from this case study and I think a lot of projects usually go wrong on some of the exact same things than this and you know everybody will always quote lessons learned. But the question is, do we always take into account lessons learned when we kick off a new project? Or do we start from lessons learned when we start assessing?

Starting to make sure, is budget going to be enough? Is it a realistic schedule? Or are we just heading in the wrong direction?

already. So the original budget was a political budget and not a real budget. So what that means is Parliament went out, the Premier, and said it was a competition, they didn't even give a costing to the guys, so they thought they knew what the budget would be.

Without any input from a construction planner, engineering point of view, they thought they knew what the budget would be and that was it. discussed in a bit more detail earlier, it was not completed before the construction was started. Then as well, major design changes took place halfway through the project where they changed the sails on the roof.

After five years they changed it, it took them another three years. So if you tell somebody it took you eight years just to design and construct a roof, if we can put it that way, it's going to sound quite silly, which it actually is. And then the design.

Technology and computer power required back in the day, for example, to do the sales on the roof. We must understand that what they intended the Sydney Opera House to be in the 1960s, it was a very advanced building for its time. So they didn't have the equipment we probably have to this date, they didn't have the technology, they couldn't design it in the computer software we have, so that when we do a project, and it's good to think of all these great ideas and how we would like to achieve it but I think we need to establish how possible is it.

Is it a pie in the sky and we would love to get there or is it in reality it's really tangible and we can actually apply it because a lot of the time we've got this airy-fairy and it's in the sky and we're going to do it and then we make the mistake and we baseline our schedule to it and we cost to it. And we don't even know how realistic it is. And it's not even always technology and computer. We can have simple things like resources in the country.

If we look at welders in South Africa these days, how many skilled welders do you get? these days and with various major and mega projects running in the country there's only a handful which means they won't even be enough to service all of those markets so if we say well we're going to weld X amount of inches and our defects are going to be less than 2% etc because we think that out of the let's say 10,000 skilled Walders we have in our country that we are going to get 5,000 of them then the question remains from a risk point of view how sure we were going to get 5,000 of those guys so how realistic is your schedule and your costing done to what we know in this point in time and what we have to our disposal. Then they had the meddling in the building design and the construction people weren't experts. They had a government wanting to build it, no construction background, didn't really make use of an owner's team or an EPCM team.

And then of course in the building design, after 7 to 8 years they fired the original architect and brought 4 new architects in, which caused total buggeration validation from scratch. They had their own ideas, trying to implement their own way. that also just derailed the whole the whole project even further and then the cost were greatly increased by labor-intensive building methodologies now what that means is that they didn't have the equipment they had back in the day as well that they had so it was more labor-intensive construction than what it probably would be today. So we've got a lot of machinery, we've got a lot of things doing stuff for us, which doesn't always make it that labour intense for people to physically do the work. Of course labour comes at a cost, it's longer hours, it's a longer duration, so if it's longer on the schedule it means it will have a higher cost or expense to it.

So what they never did is they never did a risk analysis. They never looked at any risk management, never asked if there were any opportunities, were there any threats, and if it would happen, what could they do at that point in time? to make sure that the risk doesn't happen or they face the least impact of it.

So, because they didn't have the whole risk management identification and process and risk management assistance in place, they didn't do the following things, which there's many more that we could probably list, but just from a high level point of view. So, firstly, they didn't calculate risk contingency. People always say, oh, but we've got a budget.

It's got a bit of contingency, it's got a bit of growth, another scope creep or something. But the question is, it's still not a risk contingency. Which means to me, and this is the terminology I use, is it's a P0 cost.

It has no contingency for if anything goes wrong down the line. It also doesn't have any contingency if I need to mitigate something. If I need to pay for a mitigation.

For example, how do we pay for a mitigation? So, for example, I work on an oil and gas project at the moment. So we need to have manual and controlled or mainly motorized valves installed. These motorized valves, you can't buy them off the shelf, they are casting items. So they are specifically made for this project.

Nowhere locally can they be made. actually made in Italy so we place the order in Italy and actually believe it or not it took it 40 weeks x works just to get a job was without placing the order going through a whole commercial three quotes assessment placing the order and then actually installing them on site. It took them 40 weeks to fabricate those valves and ship them into South Africa. Now, if you have risk contingency, you could do a few things.

You can buy out a production line. So you can go to the guys in Italy and say, look, we press for time. We don't have 40 weeks. We actually only have 36 weeks.

...in our schedule left, we must still install the valves etc. So can we buy out the production line? They'll probably say yes, they'll say yeah.

We'll cost you, let's say, 10 million rand if you want to buy it out. And then we might say, well we don't really have shipping time to put it on the sea, so what we want to do is we want to F rate the valves in. So it might change a 10 week lead time of...

transport to a two week if we fly them in. But of course that also comes at at quite a higher cost. So if you had made provision for risk contingency it won't impact your project budget. You will do a drawdown from your risk contingency budget, that bucket, and it will pay for the mitigation thereof. But at least it won't impact schedule.

Now when you do contingency and we'll go a bit more into detail but just high level. Is that you need to do two things or your project risk manager needs to do two things So what I usually if we sit around the boardroom table me and the construction team they will usually say well We've got two options Can either fly them in but the production line or we're going to overrun four weeks on schedule and they'll say okay Charlene So what's going to be the cheapest and what's going to be the quickest and I'll say well Let's do a calculation. If we fly them in and we buy out a production line, for example, it's going to cost us 30 million rand. But of course, we'll go and do the exact calculation.

Just giving an example now. However, for every week that we overrun this project, we will pay the contractor his P's and G's and his downtime because now he's waiting for us. Because we, maybe as the client, would supply the valves. It will be a free issue item.

Secondly, for every week we overrun... the client can't operate this facility he is losing five million rand in revenue so for four weeks the client's going to lose 20 million rand and your contractor is going to charge you two and a half million rand a week so basically it boils down to 30 million rand to buy out a production line fly in your valves is going to cost you 20 million so we would rather pay for the mitigation then face the schedule slippage however If it would cost us 50 million to buy out a production line and fly in the valves we would rather just overrun four weeks on a schedule because cost wise it makes sense and that is the benefit in good proper project risk management because the first thing if you would ask a guy what will you do he will just say we're not going to overrun schedule we will throw as much money at it as we can you don't know It's not only South Africa who has power failures. Italy might have a power failure and then a little plant comes to a dead hold for two, three days and then your contingency is already shot out the window. Even if you've paid for it, it's not a guarantee that you will then still meet your date.

Plus, now your valves get on site and you think it's all great and then another discipline overruns and it poses a threat to schedule. So sometimes to overrun those four weeks has a bit more logic in it than just to throw money at it the entire time. So very important from project risk management if we know what we face we can know what decision to make an informed decision that's a very important word big boys the Xcode guys they're usually like those big words they like colors like a heat map I'll show you and they like big words so I'll tell them you can make an informed decision to where you want to go and what you want to do cost wise and schedule wise and That's what we mainly do from a project risk management point of view is we equip them with that.

We give them the scenarios, we give them the costing, we tell them this is what it is, you choose. Because at the end of the day those are the guys you want to choose. You don't want to be held accountable and liable and say oh but you guys on site you made the decisions or the contractor or the client. You want to say well from a shareholder investor corporate strategy point of view you guys decided we were going to go this way.

Both ways will have threats, both ways will have opportunities, but it's how well we assess it, that at least when we do make a decision, and it might be the wrong decision, then all of a sudden we have the auditors, or prudency, or corporate governance. But if we can prove to them that we did the assessments, and we decided, and sometimes the decision might not always be the right decision for various other reasons, at least they will know that... We did as much as we could and we made the best decision at that point in time that we had to our disposal.

But at least also when we all make a decision then we all know which direction we're going because we don't always know where we're going. Then let's prioritise the risks. So sometimes I'll get a risk register and then the top risk would, for example, be...

People will say, weather conditions, we're going to stand on site, the biggest risk this project will face because it will have a schedule impact. I say, okay, and then yeah, down at number 10, there might be a risk like, we don't know if we have enough budget to finish this project, or the engineering is only 20% model review, and then I'm saying, why do we think that rain or wind or any of that poses a bigger threat to cost and schedule than... We're not even knowing if we have enough budget or how the whole engineering design is going to look. So very important, I like the way you're smiling, it tells me you're kind of making sense of what I'm saying, is that it's very important to prioritise the risks and rank them.

And we'll talk about in QRA, from a quantitative point of view, how do we rank risks, so that it at least makes sense from a cost and a schedule point of view. And then we... Financially plan for risk events.

So when we have a risk contingency at the top that we've calculated we can make the decision either if the risk happens we'll stomach it because it's going to cost us X amount and it's cheaper than mitigating it or we'll do a drawdown from the risk contingency and we'll pay for mitigation. Then we actually develop mitigation or treatment plans for the risk. So after we've prioritized then we will look at the priority ones of course first and we'll say well if this would happen down the line.

Because remember, it's uncertainty. It's not going to say it's going to happen. We're just trying to equip ourselves so when it does happen, we know what we're doing and which way we're going and how we're going to deal with it. And very important, who's going to make the decision at that point in time and who's the risk owner and who's going to deal with it? Because we don't want to run around at the last moment thinking, oh, who's going to look at it and who's going to do what?

We need to know everything before it happens. Because if it happens, it's no longer the risk. It's an issue. It's materialized.

You're gonna have an impact. The scary thing is you don't always know to what extent. So develop mitigation treatment plans, very important, and it needs to talk. Funny enough, if you guys don't know, a mitigation and a treatment, you never mitigate or treat the risk. You treat and mitigate the cause, because the risk will have multiple causes.

And you need to mitigate the causes in order to bring the likelihood or the impact of the risk down. You never mitigate a risk. The risk will be the risk. You need to mitigate what is causing that risk to happen, or what's going to cause for that risk to materialise. And that's why if you have five causes to a risk, you should actually have five or more treatment mitigations in place.

Because sometimes you can have more than one treatment or mitigation idea of one of the causes, but you can never have... less mitigations and treatments than what the causes are because it means you haven't addressed all the causes. Maybe at that point in time you're not quite sure how to address that cause which is fine but then you should know that you can never mitigate it away because you haven't identified all the mitigations to all the causes.

That's very important and if we can remember that we are already winning in the sense that we will know what exactly to do and what we need to treat not the risk the cause. And then of course focus on improving performance by focusing on high priority risks. So the high priority risks are usually the one that's going to cost you the most time or money.

So if we prioritise them and we know what to do to make them not happen or if it's opportunity to exploit it to get the benefit from the opportunity then we're also in a better situation than when we don't know. And then... What I mentioned earlier, assign risk accountability. A lot of people always think the project risk manager owns the risk.

Now, if that was the case, which I'm sure I would accept if I got the project director's salary, which I don't. So it's not a project risk manager's job to mitigate the risk. We play a very important role, play a very crucial role. And we are sometimes also seen as the project managers right-hand man because we're the one guy on site that goes to all the meetings and we're the one guy on site apart from the PM that interface with every discipline.

We sit with the engineers, we sit with the material controllers, we sit with the procurement guys, we sit with the commercials, we sit with the construction guys finding out what's wrong, what's happening, we sit with the cost engineers, we sit with the planners and schedule. We're the same than the PM in the sense that that integration is very important. Because if I only assess engineering risk or procurement risk, I don't know what's affecting the whole project or the whole site.

It has to be the entire picture you've got to see. It has to be this whole integration. That's why we have integration schedules as well. Because it's the integration, because usually where the integration is where the risk comes in. Might be two contractors, it might be two disciplines needing access from the other one and that's where the risk starts happening.

So it's a very, it's an integration session you have with all these disciplines on site. So to assign accountability for the risks, people always say it's the PD that needs to to be the risk owner, which is 100% right, in a sense that it is his project, it is his deliverable and ultimately if it doesn't happen he'll be held accountable unless he holds somebody else in turn accountable. So you'll have some people who say well the risk owner should just be the PD and I'll say well for the PD to mitigate let's say if it's even only 10 risks it's quite a heavy job but then I would assign mitigation owners specific people And people get this wrong. They think if you are accountable for a risk, it means that if that risk happens Then you're gonna be fired or you're just gonna lose your job. People are very scared It's like a hot potato.

Like if you want to give somebody a risk, I've seen a risk workshop guys are like no no not me not me earth and i call it i actually call it the project salute it looks like this who goes well i thought it was that guy and he thought it was me and then it's just everything's just on the floor again accountability is not about who's going to get the hiding when the risk happens because you can be accountable and you can drive mitigations day in day out have your finger on the pulse the risk might still happen it will probably have less of an impact you Or it could have a big impact where it was something totally out of your control, which you will know, which a project team will know. We're not going to hold you accountable for anything you didn't know. I mean, you only know what you know, right?

And you can only mitigate to a certain extent and what you're capable of within that environment. So what risk accountability is all about, it's just saying that I know about this risk and I'm the lead for procurement, for example, and I know we need to look at if inflation goes up, we'll buy bulk. So there's opportunity.

and cost saving. I know there's long lead items, we need to procure these things straight away. I know that fiber optic cable from an electrical point of view, it gets damaged a lot, it's quite expensive, takes some time to get here as well, so I need to order enough. spare cable so I can have it in stock so not when we run out we go oh we've got to order we need to have all those things in place and usually the procurement guy will then be well it's my department I know what's going on I'll try and manage it if I don't know what to do I'll get stuck, I'll escalate it to the PM or the PD and they will assist him in trying to manage the risk. And as soon as you take ten risks and there's twelve people around the table and each guy takes one, then you actually also start mitigating.

it because you're not looking at the whole risk register you are just looking at one little thing and all you need to ensure every day is whatever you do in your operations or in your in your daily work that that risk you just keep on remembering in the back of your head that's the risk we need to look at a few things etc so risk accountability is very important it's who do we go to and ask the questions so are we going to buy it are we going to have a cost saving are we going to have a schedule overrun so you can specifically walk to a guy specific person and ask him for that type of info and detail. And then from a risk point of view, when we look at threats, and we'll go into a bit more detail around how we treat opportunities and how we treat threats, is we can either accept and live with it. I say well there's nothing much we can really do about strikes in the country because we actually term it in construction now and it's it's the seasonal strike we call it so it kind of starts here from May June, July, August and then we know okay we'll be safe again until January then everybody goes on holiday season, everybody's happy and it's Christmas and then by May they know who's on our case and everything it is just something you can't always maybe transfer to the contract or accept it as a contractor, it's going to happen. It is what do we do to pull back schedule once it's happened and what the impact's been.

So if it's two weeks or two months worth of strikes, what do we do then to recover on the schedule? So those are the things we have to accept and live with. There's nothing we can do, especially if it's a legal strike, which quite fascinates me in terms that you can actually just apply and it's legal.

So those are the type of risks that we will just accept and live with it and we'll deal with them as they come along. Oh, we can make So we put somebody in charge saying okay you're accountable for this risk, you need to keep it updated, you need to know what's going on, you need to keep everybody informed, you need to keep your finger on the pulse. So we know what we're going to do and how we're going to do it so we can manage that environment and those risks. Then what clients really like to do is just transfer it to the contractor.

So just whatever. It's not our problem, it's his problem. Now from a risk point of view, it's a very interesting thought and concept. idea but at the end of the day you can transfer a lot of risk onto the contractor but it boils down to if those risks materialize whether you try to mitigate it or not let's just park that aside for now you still won't get your project on the date that you thought you were going to get it still not going to capitalize on that investment because you're still going to overrun so at the end of the day you as a client We'll still feel the impact thereof, maybe not to a very large extent, maybe not always financially, because you're just going to say, if the contract is risky, he's going to pay for it.

But you might have reputational damage, because you might have promised investors or the country you'll have... this up and running by this date so they have reputational loss you won't be able to capitalize capitalization you can't come back from the contractor you can claim back and say mr. contractor you'll finish it at your cost because you're running late I'm paying for it which is fine I'm going to tell the contractor for every month you delayed I'm gonna I'm gonna charge you my capitalization costs at the end of the day we can't just try sorry but it's also kept So if it's capped at the contract value, of which it's usually 10% for example, but a month in overrunning capitalisation, they might lose more in revenue than what they could on a performance or a retention guarantee. So they can pull the performance bond, whatever retention they have, but still in commercials it's kept at a certain value.

And that's also what we usually do from a risk point of view, is look at what is the exposure. Did the client and the contractor, how did they protect themselves in a contract environment? Because that's very true. There are certain things that they have to their disposal, but it's also only to a certain extent and in what contract it is, whether it's FIDIC, NEC.

So it's not just that easy to always think if you're the client, on the client's side, just to transfer it, you're going to be fine. So sometimes it's better to have that negotiation and discussion around what do we transfer, what do we accept, what do we live with. And then of course, what do we try and... avoid. So everyone will say, well, isn't avoid the same then?

Except no, no, it's not. So if we could, for example, have two areas where we can build the project, the one might be better from operations point of view, but it's going to be very difficult with a community there to construct it, where the other one, it's a bit more difficult from an operation point of view, but we won't face that many risks from a construction site. So what the client might say is, well, I want to avoid any unrest within the community, any lease agreements, any disruption to my construction or to site, so I'll rather avoid that and rather construct it here. So there are scenarios where can try and avoid risks but the important thing is we'll only know how to treat and mitigate it if we know what the risks are. If we don't do a proper risk assessment we still don't know what we need to need to do or put in place.