Why do Projects Fail? (5,219 words)

This is a transcript of the BA Video Series Linkedin Live webinar on Why do Projects Fail?

You can also listen to this video via the podcast

If you are a business analyst interested in accessing more of these topics, then join the BA Video Series now! and sign up to the product updates: www.bavideoseries.com

Speakers:

Pete Wallace

Simon Board

Elaine Wang

Vijay Nair

Intro

Vijay Nair:

Welcome to the session on the BA video series. Our topic today is why do projects fail? So for those of you who have joined, if you have been a member of our BA video series, LinkedIn community, then you will be familiar with the format of these sessions. We start the session with a quick introduction from our panelists, followed by each of our panelists, sharing their project experiences related to the topic of the day.

And our panelists today are:

Pete Wallace

Simon Board

Elaine Wang

and myself Vijay Nair as the host. So to our viewers, if you haven't already, then please sign up as a member of our BA Video Series LinkedIn group to watch our past LinkedIn live recordings on business analysis topics. So our topic today is Why do Projects Fail?

And what can we learn from this, about overcoming the challenges faced when these projects fail? On that note, I'd like to now ask each of our speakers to introduce themselves, starting with Simon.

Simon Board:

So for those who don't know me, or haven't seen me on the series before, my name is Simon board and I've been a business analyst, for roughly eight years, or longer.

I've predominantly worked in the e-commerce sector. So I've worked for two large retailers, based in London and worked for them for roughly six years before moving over to Northern Ireland where I am now working for a software quality company. So the kind of projects I've worked on are things like delivering mobile applications, front ends or e-commerce functionality. So things like delivery options and product pages for large e-commerce sites. So that is a bit of my background there. I've mainly worked on, agile and waterfall projects. So I've got a bit of experience of both. Mostly waterfall for about five years or so and then after that agile.

Pete Wallace:

My name is Pete. I worked for a very large multinational telecoms vendor. So we sell the kind of equipment that you find in mobile phone networks, whether it's base stations, big core routers or any of the surrounding databases and subscriber management. In terms of project management experience, I've worked on projects for about eight to nine years.

The types of projects I've worked on, have rolled from the very small, which might last six or seven weeks with a group of people trying to achieve an outcome and do some very major national projects, help roll out the core network for one of the major mobile networks. This project started 15 years ago and that was a full project with a lot of challenges. Last three or four years have been more about projects focusing on software development and deployment of new professional services to our customers.

Elaine Wang:

Hello everyone. My name is Elaine Wang. I have been working as a BA for last 5 years with a diverse background of domain topics. Recent projects I have been working are in the education and the aged care industry.

Projects, I have been working on most of the time is about automation of the current processes to make it more efficient and make it digitalized for our customers and stakeholders. So, I love the projects worked on, because every project is different. We used mixed methodologies (waterfall and agile) which I am still learning.

I would like to share my experience and knowledge here. Thank you for this opportunity to share with more colleagues and also friends. I learn from each other and contribute more to our community. Thank you.

Vijay Nair:

So the topic for today is, why projects fail. And I hope we can get a few learnings for our audience as well. So this is an opportunity for, for our viewers to also add your comments in the comments box. So feel free to pull in your comments at any point of this, discussion. On that note, Simon, if you can start with your project experiences please?

Project Experiences

Simon Board:

First of all, before I dive into, some of the projects I've worked on and the reasons for failure, I would like to start off by defining what's meant by project failure. Because it's easy to think that a project failed because it was never delivered.

It was never rolled out. You didn't actually deliver anything within that project, but sometimes actually that's a bit of a myth. So projects can actually fail for other reasons. So you might actually deliver the solution to customers. It might be all singing or dancing. But at the end of the day, it might fail for other reasons, such as - you forgot to consult some stakeholders or you may have not defined the requirements correctly, or you may have missed requirements.

So what would then happen is although the solution's been rolled out to the customer, it might not actually provide as much value as you thought it would. So although you delivered the project, it might fail for that reason as well. It's not necessarily because you never delivered anything. It could be for a number of reasons.

What I wanted to do is talk about a few of those overarching reasons. So first of all, it could be that the requirements were not gathered correctly in the first place, but it could also be other things like the actual scope of the project. So I'm sure we've all worked on projects where the scope has been defined within that business case.

And everyone says "I'm clear on the scope of the project". Everyone knows what they're doing. But in reality, when you're actually working on a project, often those goalposts are constantly changing. So what you plan to deliver in the first instance, you know, could change from one minute to the next and not always follow the business case.

So there's a lot of things like scope creep and not defining the actual objective, as well as the project being actually unachievable in the first place. So you could have a massive business case that promises to deliver all these functions and features. So for the customer it ends up being a bit unrealistic and you'll never actually end up implementing all of the functionality within that project.

And that's something I'm going to talk as an example of a failed project that I've worked on. Also, I've talked a bit about engaging stakeholders, and as part of that stakeholder management I think communication is crucial. So when you're working within teams, you should be always constantly communicating both.

The vision of the project, also any aspects of the solution that you think, might be changing or requirements changing, you need to always communicate both to your stakeholders and project manager. And that's, for me, a big reason why a lot of projects fail because of the lack of communication and interaction between the stakeholders, the business analyst, and also the project manager.

So a big part of that is down to that poor communication. The scope and the goals of those projects changing. So I was having a little think about this during the week. And I was thinking that some aspects of a project failure are more controllable than others. So there are some less controllable factors like the external environment for the projects and the products. Examples of more controllable elements and things that we can actually do - like the time scale. The cost and maybe the scope of the project.

So you could work closely with the project manager to make sure you define the scope correctly, and also your requirements gathered correctly. And you're actually meeting the user expectations for that project. So they're more controllable elements, but there's also less controllable elements, things you can't do much about as a BA or a PM within that.

And these are things like, if staff leave the organization for example. We will try to get on well as a team and keep each other motivated during those projects. But at the end of the day, if a project member wants to leave the organization, there's nothing to stop them. They could leave.

And that could have impacts to the delivery of the project you're suddenly working with with one less person within that team. So there are things like that that are a bit trickier to handle. As I said, the external environment. So sometimes certain products, new products get launched on the market, for example, and that almost negates the benefit for what you're doing within that project.

And I guess at some point we've all worked on waterfall projects and for me, part of the negative of waterfall without going too much into the methodology side of things, is it takes so much time to deliver that solution using waterfall. I've worked on waterfall projects that have been over say three years, for example and that's a massive scale project.

There's so much to deliver. By the time you deliver that functionality, things can be outdated. Like the product vision could completely change your business case. It could change based on those different things and external environment. So they're a bit less controllable.

Another thing for me that I found is actually funding for those projects. So sometimes sales aren't so good within the organization you're working on, money's not coming in. So sometimes the funding of certain projects could, impair your actual project going ahead, or even worse could actually scrap the project completely.

Which has actually happened to me within the waterfall environment. I've been gathering requirements for roughly six months. And then, I've been informed by the project manager that we would have to stop the project due to funding. And that's quite a common thing. Especially within retailers when sales are not so good projects can be scrapped completely.

So they're a bit less controllable. And, unfortunately there's not too much you can do as a business analyst to negate that. I'm going to talk about some ways that you can actually control some of those and prevent those project failures.

First of all, from, from a project perspective, those reasons for failure are actually completely different to what a business analyst would deem as a failure.

So for example, a project manager might be more concerned about timescales for the project or costs for the projects or budget, making sure those senior teams are happy with the solution you've delivered. And then on the other side of the coin, the business analysts would deem as failure as the requirements do not meet the required solution. A big one is actually if your stakeholders and users don't use that solution.

So they don't adopt all of those functions and don't adopt the solution as a whole. So this can be quite a common problem. Um, if you don't involve those stakeholders throughout that process and engage with them and provide some form of training as well, that that's a big one, actually training them using this new solution.

Um, cause you often find people within the workplace, they've been working with the current solution for say 10, 15, 20 years. So to try and convince them that what you're going to deliver is of value is a big point that a BA has to take into consideration. And if you can do that, then you can potentially stop a project from failing and actually your users will adopt the solution.

Also there's things like aligning the requirements to the actual scope of the project. So it's tempting within those elicitation meetings to, to keep gathering and gathering requirements and more requirements. So the point you actually lose focus on what the project was actually meant to be delivering.

So you, as a business owners, you always have to kind of, you have to, you have to keep your eye on that business case and ensure you align the requirements to that back to that business case. That's kind of something we talked about, um, in some of the previous sessions as well, making sure you don't miss requirements engage in those stakeholders and making sure you, you know, there's no scope creep within those projects.

So there's stuff that a BA can do, um, within those projects. And what I wanted to quickly finish off with is actually tying it back to one of the projects I worked in for these retailers. Um, so to give an example, um, I talked a bit about this last week, but. I was working on a project where we basically decided to launch our project, uh, our product, sorry, via, uh, affiliate channels.

Um, so what would happen is there would be an API feed that would go out to these affiliates and we'd basically sell it through, sell our products through all of these affiliates. And this might sound like an obvious. Vs a good idea. We're going to make more money because we're selling it through all these numbers of affiliates and we're bound to make more sales.

But in actual fact, what we found that wasn't the case because it took away a lot of our sales from our main e-commerce shopping channel. And instead of selling loads of products through our main website, we actually sold a lot more through our affiliates, which took away money from our main channel and users from our main channel.

So that was one of the big reasons why it fails. You know, we underestimated that impact, um, of what that would do to our main shopping channel. Also the business case. Um, it promised too much, it promised to deliver all of these amazing benefits and cost benefits, but it actually, for that reason, I was talking about 70 through the affiliates.

It didn't deliver the value we thought it would. Um, also, um, so the waterfall methodology, as I explained before, that was a big reason, um, for this particular project failure. Um, because it took us so long to, to actually. Gather those requirements go through all of those gateways, um, all of that documentation, the copious documentation that you don't get within an agile project.

I think this impacted the project quite a lot. It took time to do that. By the time we had gathered all the requirements, um, and gone through those gateways, um, the value of the project was lost and actually solutions had moved on since then. And we lost a lot of the value. Then finally, I just want to touch on actually that the type of project it was.

So it wasn't actually a stakeholder facing project. So, you know, sometimes when you're designing a new interface for a solution, you, you have the wire frames, you have the UX designs, you have the interactive. Prototypes. It's a lot easier to get stakeholders engaged because they can work with those wire frames.

They get, they feel involved in actually defining the solution. Whereas because ours was a bit more backend type project, rare, relying on API is, and, you know, cause to the e-commerce channel, it was less interactive for stakeholders which made it far more challenging. Um, to actually engage them. So that was another reason our project failed because it wasn't as easy to engage them within that.

Um, Also the processes they'd been doing for a long time, actually changed. They'd been doing things as a safe for 10, 15, 20 years. And all of a sudden their day job changes from selling products through the e-commerce channel to suddenly, uh, providing products to those affiliates and interacting with those third parties and, and speaking to them to get products on the site.

So therefore reasons I feel that the project failed and there's obviously a lot more reasons that I could go into. There's probably hundreds of reasons why a project could fail, but I thought our call, you know, call out the main four for that. Now a business analyst, um, can obviously do a lot of things to actually negate those.

As I talked about before, making sure the business case aligns to the vision, um, keeping stakeholders engaged whenever you can. Um, if you can use prototypes or something interactive for your project, then you know, that would be, um, you know, an advantage to you, um, to stop projects from failing. So. I think that's all from me really.

I think I've provided a few hints and tips there. I hope you found that useful. and on that note, I'll, pass onto the other speakers.

Pete Wallace:

Thanks Simon. For your examples, it's a nice lead in.

I'm going to step back to the kind of project management side of it, because that's where most of my experience comes from. So let's say I had about nine years working as either a project manager or program manager. And quite often I was brought into existing projects because their performance were running late.

Well, there was just a general sense of chaos around them. And when that happens, you have to figure out what's gone wrong. Why is it failing? So my approach was always to come back to four basic questions that you need to ask on every project, regardless of its size, regardless of the methodology you're using, regardless of the context of it, there's always four things you need to know.

The first one is WHY, why are we here? Why does this project exist? And that comes back to WHAT is the scope and the objectives of it. If you don't know why the project exists, you can't deliver what's required. So whenever you join a new project, whether it's an existing project or new.

If your project manager can't tell you why it exists as an entity, you're going to fail. It's very simple because no one understands the purpose. You haven't got a common focal point. So you start with clear objectives, clear scope, clear purpose. The next one is, how are we going to do this? And this, becomes really important when you work in an environment that uses different words.

You know, where I work, we use waterfall. It has a place that works really well within our business. We use agile with scrum. We use agile with Kanban. We use hybrids. We've tried scaled agile. So when you're joining a project, if you don't understand how the project's been run, which methodology it's trying to follow.

It's very hard to put yourself into that context and understand how are you going to interact with the project team? How are you going to contribute successfully and positively to it? So you make sure everybody's clear on that methodology and what it means for them. Then we have my favorite one, which is who is going to do what.

This is about accountability. You must have clear lines of accountability. Everybody must know what they are responsible for and must know that they are accountable for it. The biggest problem I've seen in finding projects is everybody knows what they're doing, but no one's holding them accountable.

There's no deadlines. There's no commitment. There's no, uh, checking reinforcing of those to make sure that you progress. Day-to-day. Now, one of my tricks as a project manager was I wanted daily updates, even if they weren't needed, because I needed to know that everybody was doing something. So if I joined a failing project, I want two minutes every day with every project member, just to find out what did you do yesterday?

What are you going to do today until they get it into their kind of behavior that they are accountable for their part of the project. They have to deliver. They can't just say, Oh, the deadline's in three weeks, I'll leave at 20 days and then spend one mad night running around, trying to figure out how to give you my deliverable.

More importantly, finding the excuse for why I haven't done it. So they, accountability is really important. I need to bring forth some the biggest challenge actually there is you often find you have to enforce that upwards. No project team members, you know, it's their job, whether they're a BA a software developer or a field engineer, who's going to do stuff outside for you.

They like to do their job. They like to do it well. So actually the accountability is not always hard to enforce that it's when you're talking to their managers or their stakeholders, or the people is functioning projection, and you realize they're not being accountable for their inputs to the project.

No, a stakeholder is not outside of the project. They are part of the project. You know, they they've stayed. They've said, I want this to happen. I've found you funding for it. I've defined what the success is going to be. That means they part of the project. And there will be times when they have to step into the project and they have to provide support for different members or different functions within the project to allow you to overcome obstacles or to allow you to move forward.

When you. Inevitably come against somebody else who wants to use your resources, you know, in big companies you find this is quite common that you've got, uh, let's say Bob, the engineer's been allocated to you for 50% of his time, which is great because that's just right. And then his manager says, well, actually it's got to be 40% actually.

No, it's 30%. Well actually, can you do without Paul? Because somebody else has come along and said, I need both for the whole time. So you then have to, you need your stakeholders to come in and mediate that discussion. If you can't resolve it yourself. And the final one is what, what am I doing? What is everybody doing?

You know, once everybody knows they're a counselor, they also need to be clear on what they need to do. So you have to document the outcomes that you want from people. And they have to be documented in a way that's meaningful, you know, an outcome can't be, can you deliver me a piece of software? You know, you have to have all of those requirements.

You have to understand how those requirements are being tested and proven. So the outcomes have to be written in a way that's really meaningful. To the person who's delivering the outcomes. They're absolutely clear on what the outcome is that you're asking them to do. So whenever you're in a project, you know, it doesn't matter what your role is.

If you can't answer those four questions, you can't that you can't explain why you're there. You don't know how things are going to move forward. You don't know who is accountable for, and you don't know what you need to do to contribute to success. The project has failed at that point. You know, it doesn't matter what the outcome is going to be because the outcome is not going to be what you're there to achieve.

It's going to be a subset of it or a variation of it. It's going to, it's going to have problems. So. Start with those four questions. And when you can answer those four questions, you at least have a chance of success. Um, and then moving on to Y successful projects that have been set up well fail. Uh, most of it was covered by song, which is great.

It just makes it harder for me to find those two or three things he didn't mention. Um, one, I would say is a bit of a strange phrase. It's a lack of pragmatism. Right. Very often in projects like nearly every day, you will find a situation where a and B are working towards the same goal, but have very different ideas on how to get there.

And somebody has to compromise. In fact, both parties have to compromise. You need to develop a very pragmatic approach. It's not about. Who's got the right approaches about what is the approach that gets us the most value and closest to our goal. And that might be some of what this guy over here wants to do for this guy over here wants to do, but it's never one, a hundred percent, one route or a hundred percent another route you're always going to be compromising.

You're always going to be trying to find. The path of least resistance through your stakeholders, through your processes, through the teams that you're engaging with to get something delivered. So pragmatism has to exist from the project manager and through the team. So you have to educate your team to be pragmatic.

You know, don't fight a battle for the sake of it. Look for a solution that you can live with and everybody else can live with and delivers what it is that you're trying to achieve. No. And I've had this several times in cross company projects. So I've worked in projects where we've had three different companies involved.

You know, we have one company that's that effectually the customer. Who's asking the other two to work together to achieve something. And you'll find because you have two different companies, you have two different ways of doing everything. So when you come together, you need to compromise on a, you know, I've walked into projects where the answer is really simple.

It can be as simple as well. If you put your documents on this server. And I put my documents on the same server everybody has access, but one company will say, I can't do that. My company controls don't allow me. I'm worried about security. I'm worried about who's going to get access to them. Yeah. And all of these questions can be answered very easily.

You know, there isn't a document server system anywhere that doesn't have security, it doesn't have permissions. It doesn't have to have both the authentication rules. Right? So these are unnecessary, um, problems that they put in there because they're scared of losing control. So you have, you have to show them the pragmatic way forward, you know, very simply it's no one gets paid.

If we fail. You know, no one gets the bonus at the end of the year. If the project doesn't succeed, you know, nobody gets asked to stay into a contract for a second year if you didn't get the first year. Right. So, you know, sometimes a little bit of reality has to come into this. So, um, the other thing is around change.

You know, every project has to change the requirements on day one, whether you're agile or waterfall, Will not be your requirements on day 30 and the requirements on day 30 and not the requirements on day 927. So you need an effective way of managing change. So you need to have a good change management structure and it doesn't need to be happy.

You don't need to have 48 different levels of change management, which I have seen you basically need three levels from a unique. The change management within the project, which the project managers should, should manage. And that's things he can see need to change, to contribute to success. But the moment they start changing the fundamental scope or the fundamental outcome, he needs to go up to the first level of stakeholders and then needs to be changed range from there.

You have to go and say, Hey, VJ, you asked for a, I can't do a, but I can do a plus a bit of fee. You know, it's almost what you want. Can we accept this as a change to the scope? Can we refocus on this? VJ so fine. Now VJ suddenly says to me, well, actually that's a much bigger scope. I don't think you understand the knock on effect that's going to have.

Then there's the final top layer where the fund holders are and the people with the big, big boots and, you know, they need to make the change. And it's important to have that change management. So everybody knows what's changed. It's documented. And when you get to the end and you've developed, I dunno, a piece of software that generates silver widgets instead of bronze widgets, people know why, and you can go back and go, you know, it was on this date, it was changed and here's, who's approved it.

Here's why they approved it. And here's the impact we thought we were going to see. Um, so th that's really why I think projects fail, you know, the lack of those four questions being asked by everybody. It's a lack of pragmatism and it's a lack of change management, everything else I had on my extensive list here, Simon managed to pull out.

So thank you so much. You can let your BC and, uh, I'll hand over, back to BJ for our next speaker.

Elaine Wang:

You need to maybe have a coffee chat, then you can continue, with those conversations.

Those kind of, failures can be controlled and also I found that normally in the informal conversation, most of the stakeholder can raise more concerns. So, that could be the second suggestion I want to add here.

Another example I want to say is about the project management and the business analysis.

The collaboration between these two roles. The BA is very happy to help with the stakeholders. And, there could be a stakeholder saying that, they want to add more scope. Yes, we can do this. We can't do that. This cannot move forward and the PM doesn't know that the change happened.

What happens is the scope is getting larger and it's causing the project failure. So my suggestion here is if its still in the very beginning stage and the PM need to be communicated at every single stage.

These two types of roles need to collaborate very well to make sure the project is delivered smoothly. Yeah, I think the first one is a lack of stakeholder engagement and the second one is lack of collaboration between BA and the PM.

Conclusion:

Vijay Nair:

Thank you, Simon, Pete and Elaine for being part of this session. So on that note, have a good day.

This is a transcript of the BA Video Series Linkedin Live webinar on Why do Projects Fail?

You can also listen to this video via the podcast

If you are a business analyst interested in accessing more of these topics, then join the BA Video Series now! and sign up to the product updates: www.bavideoseries.com