70% of Projects Fail to Deliver their Business Outcomes Transcript

Ross Martin:

Our next topic, Idris, is 70% of projects fail to deliver to the strategic outcomes. that as to why they were, you know, the why that they were created for in the first place.

Idris Manley:

Yeah, I mean, I've heard numbers as high as 80, 85%, as low as 65, 60%. But it's as low as though, the point is, it's not even below half. Yeah, it's a significant number of projects that aren't.

Ross Martin:

So the question then becomes, why are we not able to deliver projects to meet the strategic outcomes that are necessary. And again, that doesn't mean that the project might not have actually been delivered, even possibly on time and on budget. But over time, the original strategic goal of doing the project was not met. Or in some of the cases, at least for me, because we would then move and do other things after that, it's possible that there were situations where we didn't even know Because the measurements after the fact as to whether the project delivered what it was supposed to be delivered was never really followed up on.

Idris Manley:

Yeah. I think there's probably, you know, project failure is probably the most misunderstood, you know, aspect of project management. You hear these big numbers regarding project failure all the time. And, you know, within the project management world, oftentimes the assumption is that it relates to some, some risk or some issue with the project itself. However, as you alluded to, uh, you know, I, you know, in my own experience, cause you don't really have a lot of data that really explains exactly why they fail. So you have to really rely on a lot of anecdotal sort of, you know, sort of personal experience, but. You know, I mean, I've managed, you know, between personally and teams that I've managed hundreds of projects. And so I have a pretty, pretty good sample size. Yeah, exactly. And I can draw from in terms of failure. And I would argue that it's failure is related to basically a thirds. Right. So I would say that a third of projects fail because of some issue related to the actual deliverable or the fulfillment of the deliverables in the project. It could be scope related. It could be missing the schedule. It could be quality.

Ross Martin:

Under-resourced. A number of costs.

Idris Manley:

Yeah, but it could be different reasons why the project fails, right? Right, right. So cost, quality, scope, and timeline, et cetera. But another third of reasons why projects fail is because of strategy. Meaning it's, you know, you could have done everything right to execute on the project, but the strategy was in and of itself incorrect and such that, or the strategy, a strategy that led to doing the strategy or the initiatives that were defined. And so it has nothing to do with the project. But as a result of the strategy not being fulfilled, or the goals of the strategy not being fulfilled, then the project was a failure, right? And so people say, oh, the project was a failure, but it wasn't because of the project. It was because they weren't able to actually to achieve the results strategically that they intended. And so there's a third there. And then the last third I've seen is actually because of the business goals. Meaning that the goals, the business goals that were defined by the executives were incorrect. And so it doesn't matter what strategy or initiatives you would have established to achieve those business goals, the goals themselves were not achievable. And it doesn't matter what you could have done on the project side, there's nothing that you could have done to ensure that you achieve the business goals. And just to give a quick example, if a company is in a pick a market that let's say is a billion dollar market, and the company says, we want to establish a goal where over the next year, we are able to generate a billion and a half in revenue out of a market that's only a billion dollars in size. And so then they put a strategy together to go after that billion and a half in revenue, and they put project plans and program plans and set initiatives to go after that revenue. There is nothing they could do strategically or through the projects that they established to achieve a billion and a half in revenue out of a market that's only a billion dollars. And so I think Not a lot of time and energy goes into really sort of evaluating and analyzing where those failures occur outside of projects. I think it's really easy to understand project failure when it's related to the project because it's very black and white. Either you hit your timeline or you didn't. Either you achieved the scope of what was required or you didn't. Either you did it with the level of quality needed or you didn't. But it's much more difficult to be able to identify and analyze strategic sort of failures that relate to the strategy or relate to the business goals not being the right goals.

Ross Martin:

That's an interesting concept in the way that you, you know, your anecdotal evidence mentions the third deliverable, a third strategy and a third business goal, maybe misalignment or the selection of those is interesting because you could almost say then that only a third of failed projects are project managers fault. right or project team or project team's fault um but my experience has been that um it it doesn't matter whether was which one of those it is that usually the project team's uh the one that's pointed at as being not having deliverance So I think of one example we had where there was an intentional merger of two divisions, sales and marketing, into one. And the project was seen afterwards as having been a failure. And I'm sure there were definitely certain things that the project team could have done better on the delivery. There were some miscues and some of the communications and stuff I didn't think were quite up to snuff. But in reality, after a few years of hindsight looking at it, it shouldn't have been done in the first place because the merger of the two created more problems for sales and the ability to drive revenue. It was a bad strategy. It was a bad decision to even do it in the first place. But instead, part of the thing I was thinking about is how projects almost always have code names. And so this project codename was sort of became part of the corporate culture of being something you don't want to talk about because it was a failure. You know, so it's, it's still stuck to the project. Yeah.

Idris Manley:

Yeah. Uh, at one of the companies that I, uh, worked that, uh, there was, uh, they purchased, uh, a, an M or implemented a HR solution. Uh, and it was a multimillion dollar implementation of a very well-known, you know, HR ERP sort of solution. And the project was successful, right? It was an aggressive date, but my team got it done. But within two to three months of it being launched, the CFO asked, who authorized this? Who authorized this? Now, granted, he's a jerk. It was a relatively new CFO. He wasn't there when the decision was made, but he's asking, based on how much we spent with ROI, let's look at the business case. And they were trying to justify and explain. And the reality was, there were certain assumptions that were made at the time that they made the investment. The market was pre-recession. And so it made sense because they thought they were going to continue hiring and continue ramping up and they were going to be able to get more efficiencies. And so it made sense from a business case perspective, but certainly going into a recession, into a declining market where you're not hiring as many people, you're like, why did we why do we spend a million dollars, multiple million, you know, to for this that could have been used somewhere else, you know, and so I think that's a great example of a project failure, not being associated with the project, but being associated again, with some of the strategic decisions that are being made, right. And, and I think oftentimes, executives, they have a bit of amnesia, it's easy to again, to evaluate or to you know, to observe when a project itself is failing. It's pretty binary. You're committing to a very specific deliverable schedule, et cetera. But I think it's, you know, oftentimes executives, certainly stakeholders are on to the next sort of shiny object. And I think, you know, they lose sight of sort of the business case or the ROI. And so it really requires, you know, senior executives and CEO to really continue to ask those questions and to ultimately hold everyone accountable and not just, you know, PMO and the delivery function for not achieving a particular business goal.

Ross Martin:

I remember feeling, especially earlier in my career when I was more junior, probably around the director level, a little bit of the unfairness feeling around, say, executives who ended up wasting millions of dollars on something that ended up not being a good idea, and nobody ever really holding them accountable for that. They just keep moving on, and I keep thinking, I sort of assumed this person was going to get fired. But they got promoted. Yeah, or just nothing, or just complete silence. In the meantime, again, we would have certain projects that were talked about as being failures. And the frustration around that is, again, the sort of the unfairness of it all. And I remember at the time thinking, maybe that's what happens when you get up into the upper ranks of companies, is that sort of the accountability goes away. Now, as I moved up into the upper ranks and saw some of that from, you know, from firsthand, I realized, no, that's not true, but it sometimes takes longer to come to roost.

Idris Manley:

Yeah, it's interesting you mentioned that. One of the things that I teach PMO teams is, you know, because there's this misconception, you know, with stakeholders that the project is the project manager's responsibility to make sure that the project achieves its goals successfully. And that is true, that is our responsibility. However, we cannot, if certain things were not Accounted for plan for it because you can't plan for everything. You can't Assume everything right and so there's inevitably there's inherently risk in the planning and execution process Yeah, and so really what our job is really is to be able to quickly identify risks that could impede the ability to achieve those goals and to be able to ensure that there's transparency and and making sure that the right people are aware and making sure that the right change management or the right sort of negotiations are being performed based on the trade-offs that need to be considered to ensure that we make the most optimal decision at the time to maximize or to optimize the project being able to deliver as close as it can to the original sort of goals and plan that was laid out. And so this notion that the project didn't come in on schedule And so the project manager or the PMO was a failure because of that is, you know, it's, it's grossly unfair, because you really have to dig into the details to understand, um, sort of what actually result caused that to happen. And if did the PM leader, did the PM owner, did they take responsibility for ensuring that there was the right visibility into the issues? Were they being proactive? Did they engage their sponsor and key stakeholders early to be able to discuss and to come to a decision on how to sort of address some unforeseen issue, et cetera. But I think that it's important that particularly some more senior season project managers, they understand the importance of setting the right expectation in terms of what um, what they can and cannot do and make sure that, uh, that stakeholders understand that it's not just about simply bringing the project in based on the goals, but ensuring that they can adapt quickly to unforeseen issues, um, to, to remedy them in a way that isn't in the project's best interest.

Ross Martin:

Well, it makes me think of the absolute criticality of the role of the executive sponsor of the project, right? And, and you as the project manager's relationship with that person. Um, and, uh, in the best situations I've seen, the executive sponsor is, is engaged and guiding and understands their role is to remove blockers that they can remove that you as the project manager, don't have the power to remove or to make certain decisions. They don't have the authority to make decisions and in some ways help you communicate, say rough messages to the right people. So as not to derail the whole thing. Um, and, uh, those are the best ones I've seen. Um, and, uh, also when, when they see me as a project manager, uh, representing their views from a strategic point of view in meetings with the team, uh, that, that they can see that I'm saying what they might have said about something. that gives them a certain amount of comfort that I can understand how they see the strategic imperative of doing this. And I've found that they give me more latitude in that way. But there are times I remember my boss at one point saying, he was also the strategic or the executive on one of them. And he's saying something like, No, I've got this. I have to go give this message to the C suite. Like this, this is above your pay grade. Like, don't, don't take this one. Cause he's like, cause you'll get destroyed and I'll be able to give the bad message.

Idris Manley:

I mean, it's, it's, I mean, it's, it's, it's teamwork, right? Like everyone has a role and responsibility. Their role may be to really, uh, to provide coverage to the executives, to give you cover and to make, you know, and to make sure they're aligned and, and, you know, and working through those in your, your job is to work with the team and, you may have other resources and have other responsibilities. And so it's definitely a, you know, it's teamwork. It's, it's, it's really analogous to what's that sport, hockey, ice hockey, not ice hockey, but where you have to sort of ice bowling where the, I forget what you call it. Oh, curling. Oh, curling. It's just like curling where sweepers. Yeah. Where you're all sort of bowlers. Yeah. Someone is sort of pushing in, you're trying to sort of glide the path and reduce the friction and do it just right to make sure that it's the target. In a sense, a project man is very similar where you have multiple people that are playing different roles, but where everyone's working in unison to ultimately to make sure that, that the, um, is it a curl?

Ross Martin:

Yeah. Yeah. The stone. It's just a stone.

Idris Manley:

Okay. So that the stone actually hits the target. Right. And it is a very nuanced and a lot of things that have to kind of work together to make that happen. But project man is very, is very similar. That's a good anecdote. I like that. Yeah. So, so yeah, but I mean, just just, you know, just to sort of touch on my earlier comment, I do think that it's important that, you know, most executives understand that unforeseen issues are going to occur. And I think all the good ones understand, they understand those seasoned ones, the mature ones. I think, you know, it's project managers that actually need to continue to get better at setting the right expectations. Right. And I think, you know, if we're trying to wear it as a badge of honor, that, you know, we will, you know, a project will achieve all of its all of its requirements successfully, despite unforeseen issues, you're really kind of putting yourself into a corner, and you're being unrealistic. Yeah, you may, you know, there may be a project here, project there, where that happens, but you inevitably, if you've worked long enough, you will work on projects that will not meet all of its intended goals. And it will be for unforeseen issues, maybe some of them foreseen. but you will not be able to, it just won't be realistic. And it's really important that before that happens, that you're setting the right expectations that A, unforeseen issues may happen, but I take responsibility for ensuring that I'm being proactive and identifying when those things happen. My risk register, my issue log, I'm doing all of the right things to make sure that I'm aware of all of the potential sources of issues. And when they do occur, being proactive in trying to resolve it. If I can't resolve it, I will make sure that I engage you as the sponsor to advise, and I will provide you with different trade-offs in ways of looking at the problem that we can solve for it. We'll come to a decision together, and I'll implement the change management to support it, and we'll move on. You may not hit the timeline as expected, or you hit the budget target, but at least the right executives will be informed and aware and they will be a part of the decision making and feel vested in the decisions that we're making and they'll support you.

Ross Martin:

Yep. Makes sense.