In this 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: Antony, thank you for accepting to do a second interview with PMTips. Last time we talked about Sustainability in Project Management and this time we will focus our talk on the rescue and recovery of projects.

Antony, welcome. We are honored to have you with us today.

Antony della Porta: Well, I really appreciate the invite actually, Ana, and thanks ever so much for taking interest in my passion, as it were, in change initiative delivery, certainly around sustainability issue, an area which is quite a very keen area for me in particular, and has taken a bit of an ebb and flow, but certainly also for this particular part of the interview regarding recovery, which is really my background, so I'm looking forward to putting some meat behind your questions and therefore grazing some of these points for those out there who want to know or have some idea about how they might go about recovering and areas around project issues etc., so that's really good.

PMTips: That's wonderful, I'm also looking forward to your answers.

Projects, programs, and sometimes entire initiatives fail and it is imperative to take immediate action. You have been involved in the rescue and recovery of projects for many years and for a large number of companies. From your experience, what are the most common warning signs that a project is troubled or that it will fail?

Antony della Porta: Yeah, this is a very good question actually, because a lot of the times there are multiple factors that are here that could cause the failure of any particular project. You know, sometimes it's just lack of governance, understanding what the project’s all about in the first place, which is usually the biggest one, communications within the projects themselves, poor reporting or geared reporting – really not being open and transparent about what's actually going on within the project. Sometimes it's just lack of experience, poor tracking and monitoring. So, there are a lot of warning signs from both sides of it.

The PMs sometimes will be probably not the first to recognize a project’s about to fail, because of lack of experience and knowledge, and sometimes it's because they don't quite really understand, not that they don’t know what the project’s about to deliver, but really they're following a process and thinking “Well, if I'm delivering to time and costs, then I've got the quality all about, I'm getting the scope out, then I seem to be on track.” But the miss is that the projects are usually delivering a solution for the business to have a benefit out of this change, and quite often it's because either the business aren't governing properly or not getting involved in to give proper governance, or maybe just that the PM is not reporting back that understanding what the business needs to have in place, that projects start to go off track because the solution is neither not running to the plan – and by plan I mean we have an idea where we need to go for how we're tracking through it, because plans aren't locked in concrete, but they need to know where they're supposed to be going with everything – and the point is that quite often PMs miss that and therefore don't report on it properly or the business don't see that there's an issue happening either, are not aware of it, and that's part of the business’s role because sometimes they're not realizing they need to be very much involved in projects.

So, the usual warning signs tend to be a multiple set of facets or assets that are going at the time and issues popping out and you really need quite an outside eye to see this happening. Most approaches I've been on, they have realized there've been problems, so until we get in there and you get a clean eye inside it and realize that they're not tracking properly, but maybe the issue hasn't been recognized that the project’s actually heading for a cliff edge. And that's sometimes the biggest danger – we get too much into the wood we forget to see the trees and what's happening around us. And that's maybe splitting it up into various aspects of what the project’s up to.

PMTips: Troubled projects place organizations under a lot of stress. In order to avoid further project failure, must the organization be repaired as well? How can organizations and project stakeholders approach such a major change?

Antony della Porta: It's not always necessary that the organization needs to be repaired as well, but it's very true they do go through a lot of stress because they've got financial investments in these projects and also these projects are supposed to be delivering a solution to help them move forward. Ironically, back to sustainability, because most of the time we're trying to keep our organizations functioning and be competitive and be sustainable, most of the time it's more about the organization probably needs to review the way of the practice it puts in place to run project initiatives and how it therefore populates those with the right skills and the people that it has involved, project managers and anybody else involved in it.

All right, so quite often it's more how do we get better governance to get the business involved in it better and therefore realign our particular practices and understanding on how we run our change initiatives within our organization. And, so the project stakeholder, for instance, really need to take that on board as a cultural change and realize that if we don't do this, then we're going to have the similar problem next time around and it's going to cause them bigger stress financially and organizationally as well, from a point of view of how we're functioning as a company to deliver you know products out there, whatever we are doing for our clients. So, it's quite a change and it's often very difficult for organizations to take that change initially, but once the initiative’s got on and running and they've got to understand that they need to be or have agility in the way they do that and the way they run their changes, then they will start to make progress and move forward, and quite often reduce a lot of the faders that come on board, for instance recognizing that we need to look at benefits-led changes in the start and understand why we're making this change in the first place, which is quite often one of the reasons why projects tend to fail, because they lose sight of what the hell we’re here for in the first place.

PMTips: What kind of support should project managers be given when faced with a troubled project? Is there something that the organization can do, particularly in terms of applying appropriate methodologies that can get the project back on track?

Antony della Porta: Usually the first thing is not to take a blame approach. I think it's very unfair when the fingers start pointing at PMs themselves. It's true, they are at the coal face and they are the key reporting and therefore updating mechanism to the business themselves. But it’s not necessarily the project managers, and as we said in an earlier question, because there are many facets and reasons why projects fail, not all of them are down to the project managers themselves either. So, therefore other people need to take a bit of accountability and responsibility for some of the situations that projects get themselves into.

So, the first thing I say to you is “Look, don't take a blame, let's look at the situation we're faced with and try and work out what the core issue really is, what's troubling the project and find out how we can actually fix it up. Now, obviously following current methodologies, or at least taking an accumulation and sort of a proper tool kit out of those methodologies as a hybrid to the way that particular project needs to run, it's always a good start to try and avoid some of those issues, but maybe look and see why we suddenly got off-track, and quite often it's because we're not following a sensible and a realistic way of running projects, because there are only four phases we actually go through in projects. We need to have a high level view of why the hell we're here, why are we running the project in the first place, and have a gray of ground understanding, and this is sometimes, as I said earlier, that gets missed. Once we've got an understanding and a clear view that we know what we're doing here, cumulative as a collaborative understanding, then we can put a lot more design behind a project that takes a bit more time and spend more money, you know, basically put the planning in place. So, that's the detailed part of it. Then we can run that plan and start going through the delivery of the solution, and at the end of it we actually deliver the solution the way we made it, deployed it during, and then deliver at the end of it.

The key thing is that people tend to jump from a high level view and start to run something before they've even understood what it is about we're running here, and therefore look at the detail of those, a sensible detail, but not a massive detail on what we're running the project for in the first place. So, part of the problem is that methodologies don't get used properly when they're not being applied properly, and look at the simple logic behind them. So, it's often not a good idea to just sort of jump on the project managers straightaway, [but] sit with them working out, because there are many ways that these things go wrong and therefore take a bit of ownership, but try and find out what's causing it and how do we fix it up.

PMTips: What is the best way for project managers to prepare a fail-safe recovery plan for rescuing failing projects?

Antony della Porta: Yeah, now this is a good question, really, because there is – I was trying to look at this. I'm not really sure there's any real fail-safe recovery plan. There are certain key things that we can do once we recognize that a project is heading or is floundering already, so there are indicators of that, either because there's a lack of sponsorship or the project manager is fairly uncertain about what they're doing here or they're trying to be too confident in some respects and therefore the information is probably not reflecting the real situation here. Sometimes it may be that the scope of the project has been misunderstood and therefore the solution coming out is not doing that, and one thing that can help actually track that very quickly is taking a much more what they call an iterative or an incremental approach to the deploying parts, all these getting parts of the solution out there earlier within the initiative itself and therefore we can get feedback pretty quickly from that.

So, when it comes to recovering the projects, a lot of it is revisit why are we running the project in the first place, get back to the business and say “Look, this is the initiative. What's the real goal here and the vision and therefore what are we trying to achieve from a benefit point of view? And, is the solution we have in place really doing that? ” And, then we'll get back to the key elements of that solution and what do we actually need to do.

A few years ago we were looking at recovering an outsourcing program for a financial institution in Australia and they were trying to outsource a lot of their developing work. The problem was that the original guys who got involved and got too deep into one particular aspect, which was designing the network connection between Australia and the outsourcing country, well they forgot to look at the bigger picture, and so it became very evident that we needed to go back and find out what are we supposed to be doing here. In fact, they didn’t even have a plan in place quite frankly, so that was one big indicator they weren't going very well, and therefore they'd lost the focus on everything because they’d got too deep into the picture and we had to pull them right back out and look at the bigger picture and then try and work out “What are we actually trying to achieve here? How do we do that? And what are the key elements to help us do that?” So, these are some of the tools that help us find out and realign the project back to what it's supposed to be doing. And, of course, one of the key elements we have done is prioritization, for which there are various methods – Moscow is probably one of the most useful ones – but prioritizing your project is key even when you're starting it up, but certainly when it comes to troubleshooting, so I think that's one of the first things to think about.

PMTips: How important is it for all project stakeholders to clearly understand the project rescue process once it has been initiated?

Antony della Porta: Yes, well the key thing here really is they need to understand there’re responsibilities for providing advice and direction, and supporting the initiatives that they've put in place, and supporting the project’s managers who are trying to get the thing back on track, too. And therefore take a lot of support from that point of view and sponsor, if you like, the rescue process that's been agreed upon, but take some ownership, too, of that because they need to provide the advice and direction, that's their responsibility and their accountability for it.

At the end of the day, the stakeholders, especially the key stakeholders and the business key stakeholders – it's their project, it's their initiative. The PM's there making sure that everything works for them, so really they need to understand the rescue process, have signed off and agreed to it, still have the agility that it might have to be changed a little bit as we go along, but at the point that we agree at this point in time and provide that support to the PMs in particular, that’s very important [that] they do that.

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