Pulling it all together, Joe Patel, our Head of Product and Client Relations, provides his own guidance. He draws on his experience to provide several practical takeaways that could make a significant difference to your approach.
Every project starts with high expectations.
Yet reality can be quite different. According to project management experts Wellingtone, only 36% of organisations ‘mostly or always’ deliver the full benefits of their projects.
These findings are not a one-off. For years, research has claimed around 70% of projects fail. And not just IT-based ones. Classic examples are clear to see.
Remember Sony Betamax? Its lack of innovation resulted in the business losing market share.
Meanwhile, McDonalds didn’t understand what their customers wanted in 1996, failing to let customer data drive product strategy. As for Airbus, lack of communication across engineering and designing teams led to misaligned manufacturing
In both these cases, the initial project was a success. But the long-term result was anything but. The first of three articles, we look at what project success can look like and how you can help your organisation deliver successful software projects.
What do you mean by ‘success’?
To decide whether something has succeeded or failed, you must first know what you’re measuring. Many differing opinions exist on the subject.
Suffice to say, you must consider what your ‘success’ looks like from many angles. The answer is rarely black and white.
At the most basic level, you’ll have a budget, timeframe, and scope for your software project. Should your outcome tick all these boxes, it’s a success, right?
This approach only focuses on the project delivery. It doesn’t consider whether the project sufficiently benefited your organisation and end users.
Every project relates to a desired outcome. So, you could assess how successful the project has been in achieving that outcome, in the short and medium term.
This is a bigger picture approach, but still risks relying on an internal point of view.
Another way to measure success is to assess whether your project achieves the objectives set by various stakeholders. That might include several internal departments and external parties such as suppliers or end users. They’ll often have different goals though, making measurement harder.
So, perhaps you could measure success at a more strategic level? Does the project outcome support future opportunities and organisational growth?
What about value?
It’s clear defining ‘success’ can be more complex than first thought. So, let’s throw in a curved ball…
Should you measure your success or the project value?
Ask yourself this: “What makes this piece of work valuable to each party involved?”
Your scope now widens beyond completing the project on time or achieving your business goals.
It also prompts the need for deeper insight to establish what ‘value’ looks like – both internally and externally.
For example, UX teams could create various user personas. They would then research how each persona might use your product and gain value from it. Consider older and younger user attitudes towards a new interface. Think how their needs could vary. If you can’t deliver value to both user personas is your project truly a success?
There are countless examples of this. Software projects deemed a success, but impressively flopping when launched into the marketplace due to lack of relevant value.
Success or failure?
So, the definition of success can be wide. Every project is likely to have many success criteria because it’s never down to one thing.
With this in mind, a tiered approach to success measurement can be helpful. It enables a broader, multi-level explanation that isn’t vague or muddled.
Three common tiers are:
- Organisational vision
- Key indicators
- Goals and value by department (or stakeholder)
You can break these down to weekly or monthly goals too. By progressing in small steps, achieving bite-size goals, you can regularly check everyone is moving in the right direction.
Of course, goals can change, so flexibility is crucial. For example, in the early stages, you might receive negative feedback about your design and need to adjust it.
Small adaptions are inevitable. But an excessive need to change would suggest insufficient preparation at the outset. And success certainly depends on a clearly defined path to move forward from.
What’s behind most failures?
There’s no shortage of documented reasons for projects failing. Project management expert Wellingtone confirms this. Only 45% of respondents say their organisation has a track record of project success. Which leaves 55% in a less satisfying situation.
There’s a more interesting point here, though. Take a step back and consider where these ‘failure’ reasons are coming from.
Whilst some relate to project execution challenges, many point squarely to poor strategic planning.
- Unclear objectives and lack of a roadmap
- Insufficient senior management involvement
- Unrealistic expectations
- Overlooking the benefit of an MVP
- Limited resources
- Internal politics
- Choosing the wrong software partner
- Poor communication
This insight suggests one of the best ways to avoid failure is to take a more strategic approach to your software development projects. Not only for planning, when you’re measuring success too.
Project or product – what’s your priority?
In our experience, organisations partner with bespoke software providers to gain support and development for the life of their product. Rarely a one-off project, they need several pieces of development over time. All driving the product forward to achieve greater success.
We see projects as part of the product development plan. Part of the bigger picture.
This begs the question: should organisations favour recruiting product managers over project managers? Of course, some already do. And for others, the two roles can overlap.
We’ve seen that when you focus on your product instead of each individual project, you naturally develop a more strategic approach. You question how that project fits into your wider business eco system. And your mindset shift influences primary success factors.
In fact, we think understanding your product strategy can help you become more proactive about project management. For example, you might establish the right time to achieve project success.
An interesting example of this was during the rush to create mobile apps when the technology was relatively new. Apps felt like a modern move and many organisations quickly jumped on the bandwagon.
When they delivered their app to the market, many deemed the project a success. But there was another side to this. Over time organisations realised they’d given no consideration to app lifecycle management. What about upgrades and new user functionality? This led many organisations to promptly retire their apps.
Was the project a success or failure now?
Had they taken a more strategic approach to product management they might have completed other projects before launching the app. They might also have considered the longer-term requirements of such a tool.
A strategic approach to success.
We’ve highlighted how software development success and failure is not black and white. We’ve also touched on the value of taking a higher-level strategic approach to software planning and success measurement.
Software development is instrumental to your product’s (and organisation’s) life. It’s easier to appreciate this when not seeing projects as stand-alone activity.
We’ve found this simple change in approach can improve your planning and your success criteria.