28 Jan Why is your technology project failing?

Late last year, the Queensland Audit Office released an excellent report into delivering successful technology projects.

Based on current spending data, the Government of Queensland has 1.6 billion dollars invested in around 116 existing active projects. Of those projects, 38% of them have requested additional funding increases, and 53% are currently operating on extended timelines.

In 2018, the McKinsey Center for Government did a survey of 3,000 public officials across 18 countries and found that 80 per cent of public sector transformations fail to meet their objectives.

What is it about technology projects that makes them so difficult to complete successfully?

Good Teams Deliver

As part of the QAO Report, the Auditor-General identified the following six key success factors:

Projects are Aligned with Business Outcomes

“…Many technology projects in government are started because there is a need to avoid the cost of a failure in a legacy system (an old system that is no longer supported by its developer) …”

QAO found that if the team that understands the business outcomes works actively and closely with the project team, the project had a greater chance of success. The people who understand the business problem and the legacy system should be the people who actively work on the solution.

The Team has the skills and capacity to match the challenge

Technology Projects are high risk and often require specialist skills in advanced development, testing techniques, project management – project teams without adequate expertise in these chosen disciplines are more likely to fail.

Senior Leaders actively lead and challenge

Good hands-on leadership and active executive sponsorship are two hallmarks of successful projects.

Internal and External Teams work towards the same goals

If you’re working with an external development agency, or an external software provider, you often end up with hybrid teams from both organizations, sometimes working in different countries. When the alignment of these two organizations is different, for whatever reason, then the project will tend to veer off-course. Consolidated, clear direction and effective use of incentive is critical in these situations.

Learnings are identified and acted on

“It’s only a stupid mistake if you make it twice”, as the old saying goes, but too often the failures or successes of previous projects aren’t captured or considered when undertaking technology projects.

These are all excellent observations – the strength and effectiveness of the team as a whole is crucial to success of any project. A great team will overcome even the most ardent challenge.

Choose your Problem Set

But there’s more to it than just team dynamics. Most projects start with a statement something like:

“Either we build something from scratch, or we buy something that already does this.”

This Build/Buy decision, more than any other, determines the kinds of problems that your technology project is going to encounter.

Build

If you build, you face the risks of unknown estimates, complex dependencies, quality management.  You have the overhead of having to define, document and detail your business so that you can adequately explain it to a development team. You have to manage external stakeholders and delivery expectations. Software Development Projects have a complex development cycle that depends on the team being acutely aware of everyone’s responsibilities, and as such it can be quite brittle – failure to execute at any single phase generally affects all the others.

On the upside, you also have complete control over the project output.

If your requirements are particularly unique, you may have no other option than to build a dedicated solution.

Buy

Buying a solution can save you time and money and also offsets the responsibility for project risk.

If you buy, then you have a whole different set of problems. Most importantly, you have to bridge the void between the way the software product you bought addresses the business problem, and the way your organization sees the problem.

In our experience, it’s really rare for these two things to line up exactly. So now you have two ways across the divide – you can configure or customise on the software side, or you can modify your approach to the business to better match the product, which comes with a significant change overhead. These unknown factors are the primary source of delays and budget overruns in a COTS Deployment.

Assemble

At Dinode, we think that there is a better alternative to Build or Buy – Assemble.

We’re making xMS to include all of the common building blocks that comprise enterprise software. We want a smart business analyst team to be able to put those together using their expertise and business knowledge to deliver the best of both the buy and build approaches to the organization.

By using a no-code platform like xMS to design and host the enterprise application that you need, you can leverage your internal business knowledge and experience, free yourself from external dependencies, and avoid chunks of legacy thinking creeping into the project from other systems, bringing more predictability and control into technology projects – which translates to better use of time and money.

Get in touch with us! We’d love to hear what your project challenges are.