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.

 

Interview conducted by Ana Mitevska