If you heard about a project that came in a year late and twice its original budget, you’d probably assume that it was a failed project. But when we talk about failed projects, it’s more important to consider whether or not they delivered business benefits.
It may surprise you to find out that the movie Titanic came in a year late and twice its original budget, and I think you’ll agree that as a project it was a success. The fact that it came in over budget and over schedule doesn’t mean it failed – Titanic was a success because it delivered business benefits.
So how do we stop projects from not delivering on business benefits, and therefore failing?
The first step is to make sure that your project is solving the right problem (and that it’s a problem worth solving).
Too often we see organisations implementing a project because it seems like a good idea, or they have been sold a ‘solution’ by another company, or simply because they have some spare budget.
Don’t just start a project blindly.
What needs to be put in place is an understanding of how to identify change and create projects that will deliver business benefits.
This means beginning by investigating and acknowledging where the problems exist in the organisation at this moment.
Next, you need to uncover the root causes for these problems, not just attempt to solve the symptoms.
Then, it can be decided where the organisation wants to be in the future, bringing light to the gap between where the organisation is now and where it wants to be.
Finally, once you have a clear view and understanding of this gap, you can decide on and design the best solutions to bridge that gap. A well-crafted business case is critical to this.
When you are creating the business case, you need to ensure clear stakeholder engagement in addition to well thought through options. As a business analyst, it is not your job to tell your organisation which is the right solution. Your job is to present a shortlist of solutions to them and help facilitate their preferred option.
Once the project has been completed, it’s then necessary to undertake the business benefits realisation process. Without doing this, you are just hoping that the benefits were achieved. But when you undertake this process, you’re able to categorically prove whether the benefits were achieved or not – and if not, adjust and take corrective action.
It’s a safe bet for us to say that many of you reading this will have been involved in a post-project review that focused on how the project was run, but didn’t touch on whether or not the project achieved the benefits that you had hoped for.
There is no point in starting a poorly conceived project. For a number of organisations, this may be the default and it is a sure path to failure.
A lot of time is spent making the project deliver within budget, but if that project is the wrong project, then the question to ask is this: would that time have been better spent scoping the right project in the first place?
As a business analyst, it can be easy to land in the mindset of: “How does this apply to me as a BA? I have no say in how my company chooses its projects.”
But the next time a project goes astray due to poorly conceived ideas, it is your chance to speak up and say: “We should be thinking how to start projects better, rather than trying to fix them when they’re going wrong.”
The best way to avoid the failure of a project is to start it the right way.
To get your projects off on the right foot, we recommend the BCS Certificate in Business Analysis Practice – click here to learn more.
Share