In this part of the interview we ask expert Antony della Porta how to best apply critical systems thinking (CST) in the recovery of projects, and if focusing on sustainability can help troubled projects. We also focus on what the impacts of delaying the declaration of project trouble are, whether that increases the risk of the project being canceled, if there is a way to determine that the project is not worth saving, and when is it time to gracefully execute the termination process. In the end we ask for his advice to project managers that face troubled projects.
PMTips: How can critical systems thinking (CST) be best applied in the recovery of projects, but also what are the benefits of its application?
Antony della Porta: Objectivity is the real benefit here, because by taking a view from what the critical system thinking or thinking of what the system is doing here, you're pulling apart the whole project and what it's looking to deliver. So, what is the vision behind all this? What are the key elements of that that bring that together to understand how they all fit together and look at the key areas of those, and where the interactions are between them? So, get a little bit like a rich picture, if you like, and therefore you can start concentrating on where is the key set of elements that link up.
So, back to the outsourcing program – the key element was [that] we needed to get guys sitting on their desk in the other country onto their PCs with an access through the network in the secret system to look at the developing systems in the other country, in Australia. And that was taking the thing apart, looking at what is the key system here, what is the key element we need to have in place. Once you understand that, it helps to provide a better understanding how we're going to put the plan in place to therefore recover the project, can we now know what we've really got to deliver as a key set of elements in the products, the objectives to deliver, to get the solution through in the time frame we have left or whatever time frame that is.
So, sometimes even looking at that is saying “Have I got a realistic time frame to be able to achieve those objectives in that time frame and realign them with the outsourcing program – we didn't have that, we had to increase the time frame by a couple of months and also the budget really, because they'd messed up on the budget. But the point was we knew what we had to do and the bits that were missing to complete the picture and that's when the systems thinking comes into place and the benefits help you recognize very quickly what the situation is, what you need to recover from, and therefore how can you plan to get that recovery back in place and get the project back on track, a lot quicker than if you're just trying to look at the particular issue. And that's sometimes where it gets misleading.
PMTips: Can focusing on sustainability when working on projects be of help to troubled projects? Does it always instigate changes on an organizational level? In addition, can it prevent failures from reoccurring?
Antony della Porta: I was trying to look at this, you know, where sustainability comes into – it depends on your viewpoint on sustainability. If we take it back out a little bit and look at sustainability from an organizational perspective, there are quite a lot of different areas – this is not just carbon foot printing. But if you look at the organization keeping itself current, and therefore viable from a point of view of the service or the business it's providing to the broader global picture, then reputation is also a part of that.
So, sometimes we've got to be very careful that projects can run into trouble, because we begin to realize that actually that what we are delivering might well have a major impact on that area of sustainability, like reputation for example, or we're producing something or running something that really is not part of the organization's mission and therefore strategy. So, that gets back up to the organizational role, because at the end of the day they have that responsibility, they’re accountable for that at that level. Therefore, quite often at the organizational level, sometimes what we call the portfolio level, understanding the gambit of projects and programs that are being run in that particular portfolio, or the broader organizational portfolio, can give a better understanding of whether we've got projects that really should not be running, and now we've got them going finding [that] actually these are ones that we shouldn't be doing. What can cause that sometimes is that because the way we try to govern some of the projects that run and say we need to put the governance and decide on that project. Because it's quite a low-key project, because [of] the way they put the business case together, the problem there is that some initiatives get run that should never have been run in the first place.
And it's only later on that that would start to raise concerns and therefore become a troubled project, because we've realized that that project’s running into a situation where it’s causing problems for the organization because it's delivering something we should not be doing, or it's clashing with other projects and programs that are running too, and therefore absorbing resources that really it shouldn't be doing. So, there're various sorts of ways of doing that and really getting a better view of a portfolio perspective, understanding the initiatives that are running in the organization in that portfolio or the organization as a whole, how the impacting on the way we see us as our mission in life, and therefore what are we trying to achieve in that mission, the objectives we need to have in place, and how those projects are actually driving those strategies to help us achieve those objectives – are they relevant or not, how they’re going to impact us or not. And that will keep us sustainable. So, there is very much a link between them.
PMTips: What are the impacts of delaying the declaration of project trouble? Does it increase the risk of the project being canceled?
Antony della Porta: I won’t say it increases the risk of it being canceled, but it certainly increases the fact that it should be canceled. The risk isn’t really around whether it become canceled because we're delaying it, but there is a big risk, of course, that it might have a bigger impact on the organization – a little bit linked to the question where we were talking about sustainability. The delaying it is more of a psychological risk, but also can have a major impact on the way it's draining resources that could be used elsewhere, or the fact that it will be going down a path where it gets past where we can actually recover it and therefore have to cancel it because it's now not delivering what we need to deliver.
Sometimes that's because scope creep changes, as we watch scope changing, not so much scope creep, but we get scope change [which] should be authorized, which when it isn't becomes scope creep, and therefore end up delivering something that is really quite different from the original business case understanding, and what therefore the organization is expecting. And that's partly because it's not being governed properly, too, sometimes or the project manager has just been allowed to allow things to happen, sometimes because they just feel they've been overruled by lots of things. There's some interesting films being produced on some real programs out there that show this just happening: they end up supposedly delivering one solution into something completely different.
And the problem is the more we delay, the more we have a drain on the resources and therefore get to a point where it will actually end up being canceled. So, you could argue, yes, in that case it's not just the delay, but the fact is that the more we go down our hole and not looking at the right solution, we could end up having to cancel because now we’ve just lost complete faith and confidence, and the solution’s going down the wrong way in the first place.
PMTips: Is there a way to determine that the project is not worth saving and that it is time to gracefully execute the termination process?
Antony della Porta: Now, this is really where business governance actually has to come into the picture really. They've got to make that decision themselves. Now, they can only make that decision based on the information they are being given, because that comes up from the project manager and any other resources or sources of communication that are in place to help them make those decisions. Part of that is obviously the way this solution is being delivered and what the solution is actually doing.
So, quite often the business [has] to work out [if] that is actually going to achieve what [they] wanted to achieve, which the first thing is about the benefits. So, they'll set boundaries around the benefits that've been realized within the project and say “OK, they're not achieving what we think they're going to achieve, we don't believe we're ever going get to do that, so quite frankly it's not worth going any further.” Or technically it just can't be made, sometimes they get in and realize at the end of the day that the solution isn't going to be viable. We had that, – well, it's bit before I got to a particular company – they were trying to change the way the bank teller system functioned, but at the time the technology was just not going to work. So, quite often [with] running proof of concepts, a quick understanding at a high-level earlier in the project helps you determine that very quickly – is that technically viable or even if it is, is what we are producing what the business really want and therefore going to do what they need?
So, usually the first thing is around the benefits and see if that's happening. So, we're going to get an earlier view of that solution for the business to make that decision, and then it is their decision. But we've got to give them the right information to do that. Other ways around that are looking to see if the risks are greater than we expected, so we need to understand what the risks are at the beginning and have we actually got into a situation where the risks of delivering that for the solution itself or the impact on the organization are really not something we want to do, or just other resources and funding.
Those two can help make determinations very quickly, whether it's time to pull the plug basically and therefore cancel the project. And it needs to be done, and if it's got to be done, someone's got to make that decision. Someone's got to be accountable for that and that's why it’s usually the person who owns the project overall, they should be making that decision because they understand whether that's the right thing to do or not.
PMTips: What is the best advice you can give to project managers that must face troubled projects?
Antony della Porta: I'm curious about the word ‘must’. So, the interesting point here is: I end up facing troubled projects because that's my background in troubleshooting projects and programs, it has been for years, and troubleshooting most things actually. Maybe that's because I have a bit of critical systems thinking approach to doing things. So, if I must face a troubled project usually the best thing to do is try and gather as much information you can about what the project’s supposed to be doing, where you think it is right now, and therefore what are the key elements you need to concentrate on to deliver. But at the same you want to work out why are we actually having a problem here in the first place and try to get to the bottom of that, because there's no point getting it back on track if some of the root issues are still there that are causing the thing to fail in the first place.
So, PMs have got quite a few things to do when they get on board: firstly, they need to understand where are we right now, what are we trying to achieve here, what's the current understanding that we've got to a particular current problem that I've had to come in and look at it, and get to the bottom of that and try and see how you can recover that first of all. Alongside of it, looking at if I can get the project recovered, what are the key elements I need to concentrate on to make sure I get those across you know and delivered to satisfy the business, that we've got the key elements out of it, the main objectives of the project, what they call the must-haves, if you like. Those features or those key objectives that I must deliver to get this solution to work, can I achieve that and look at what I might have to go back to propose to them. Which we've had to do before, now like an earlier example, I ended up having to go back and say “Well, we've got to remove some of these particular objectives, because we can do without them right now; we need to change the time frame, because I still need more time because the elements are being missed, and at the same time I need some more money because that's being missed off, too; we need to increase the budget because we're already running out of money as it [is]”.
So, it's a case of getting all those things in place, but take like a cool objective view, going calmly to talk to people, work out what's going on – you need to assimilate all that information and hopefully come to some understanding [about] what's actually happening, and therefore what you need to do, knowing what you need to get across the line at the end of it and how you might recover it to do that in the first place.
PMTips: That was the last question. Antony, thank you for the interview, it was an honor and a pleasure.
Antony della Porta: It was my pleasure, too, and I really thank you for asking me to provide some new information I hope that anybody who's listening to this here afterwards will [get] some comfort, some advice and take some food for thought on things to understand about how we recover projects and try to avoid getting in that situation in the first place, as well, that's the another thing to watch out for, too. And thank you very much for the opportunity, Ana, and it's been a pleasure to provide that advice hopefully, as well.
PMTips: Likewise, likewise. Thank you very much.
Interview conducted by Ana Mitevska