Failed IT Projects – ‘Misunderstanding of User Needs’ is top reason; 5 steps to assure a much better outcome

By Allan Watton on

Confidence is a vital element in any major IT project relationship, confidence in your supplier’s ability to deliver on your expectations – as the length, cost and disruption involved in any such project can be significant, alongside the risks associated with them.

However, according to research undertaken by Public it stated data published on GOV.UK would suggest that this trust is increasing in fragility, or may even be misplaced at times, as the biggest cause of projects that failed the government’s own minimum standards assessment, as set out by the Government Digital Services (GDS) department, was misunderstanding of user needs.

This article offers some guidance on the most successful criterion we have evidenced on how you can give your major IT project relationships a greater chance of a better outcome.

The History of Standards

According to the article, six years ago, after a year of beta testing, the government introduced the Digital by Default Service Standard, a 26-point test to assess whether a project’s outcomes were fit for purpose. All 26 criteria had to be met for the project to be passed. Over time, this assessment and the standards that projects were held up against have changed. A year after its official launch, the 26-point test became an 18-point test, which last year became a 14-point test.

From this article, we are assured that the standards have not been lowered, but have merely evolved and changed. The essence of the lost points in each assessment were, in most cases, simply incorporated into other assessments that were retained by the GDS.

This analysis is reported to evidence that, over the years, the failure rate has been fairly level. Interestingly, and applause from us for transparency, some of the projects initiated by the GDS itself appear to have been among those that have failed.

What Does the Standard’s Checklist Look Like?

As it was the 18-point test that was in place for the longest period of time since the inception of the assessment, we’re using this as our foundation for this article.

This checklist of requirements are as follows:

    1. Understanding user needs
    2. Improving the service based on user research and usability testing
    3. Having a sustainable, multidisciplinary team in place
    4. Building using agile, interactive and user-centred methods
    5. Iterating and improving the services on a frequent basis
    6. Evolving tools, systems, and ways of procuring them
    7. Managing data, security level, legal responsibilities, privacy issues and risks
    8. Making code available as open source
    9. Using open standards and common government platforms
    10. Testing the end-to-end service, and browser and device testing
    11. Planning for the service being taken temporarily offline
    12. Creating a simple and intuitive service
    13. Ensuring consistency with the design and style of GOV.UK
    14. Encouraging digital take-up
    15. Using analytics tools to collect and act on performance data
    16. Defining KPIs and establishing performance benchmarks
    17. Reporting performance data on the Performance Platform
    18. Testing the service with the minister responsible for it.

From this list the three most commonly identified as the reason to fail a project, were:

#1 ‘Understanding user needs’, with 25 of the 34 projects failing on this point

#2 ‘Creating a simple and intuitive service’, impacting 23 out of the 34 failed projects

#3 ‘Improving the service based on user research and usability testing’, impacting 20 out of the 34 failed projects.

For a project to pass, it must pass all of the tests in the assessment. And it should also be appreciated that failing any one test does not mean the supplier failed that test completely, simply that they did not do everything necessary to satisfy the requirements of that test. For instance #1, understanding the user’s needs – if it is determined that while many of the user’s needs were uncovered, some were not, this may be the reason for this test to be registered as a fail.

An example of this, shared in a article was a project from last year to ‘Find an energy certificate tool’ by the Ministry of Housing, Communities and Local Government. It’s reported that…

‘The assessors’ report said: “It is evident from user research that the team have been able to identify most users of the service. However, the assessment panel felt the numbers – 34 – spoken to is not enough to state that all user needs have been uncovered which would have resulted in breadth of insights.”

It added: “The panel would have liked to see more around what users are trying to do whilst encountering the service, how they interact with the service face to face – moderated testing – where users currently go for help and more around their thoughts, circumstances and behaviours.”

Five Steps to Achieving Clarity Over Understanding User Needs

Having worked with hundreds of clients over the last 20 years to help them develop, optimise, rebuild and exit their major strategic project relationships, we have identified certain commonalities in those that are most successful. We can summarise these in the following five steps.

    1. The art of outcome visualisation

In order to achieve the most value in your relationships it’s vital to understand your destination, the objectives and outcomes you aim to achieve as a result of the collaborative relationship you are looking to build with your supplier. This can be achieved through internal analysis (to determine what specific goals will signify the successful completion of the project or the achievement of the desired result, and to quantify this benefit to assist in the development of a business case for investing the resources you will expend on your route to these outcomes). Alternatively, it can be achieved with the help of your supplier who may well be able to identify opportunities for optimising the process, critically assessing the viability of your aspirations and defining ways of adding value.

    1. Clearly determine your starting point

A clear path forward is only possible when both you and your supplier have a complete picture of how services are currently being delivered, the form and costs of the issues you are currently facing and where challenges are holding you back from your aspirational position. The clearer the picture you are able to provide for a supplier, the more likely they are to be able to identify optimised roadmaps to your desired outcome. Importantly, this also means that there will likely be fewer undefined challenges to discover along the way that will impact on your supplier’s ability to achieve those outcomes within the schedule and budget provided.

    1. Define ‘what good looks like’

Identification of the outcomes you are aiming for, as set out in point one above, can now be expanded on. It’s important to be able to specifically define the transition between where you are currently to what ‘good looks like’ in a future where your project has been successfully implemented. What do you imagine being able to do differently, how realistic is this, what are the knock-on benefits achievable or expected? This is the launchpad of a successful collaborative relationship, providing your partner with the information they need to be able to work with you to define a solution that achieves your goals.

    1. Invest in pre- (ideally) or post-contractual due diligence

Providing your supplier with an opportunity to not only define their solutions, but also explain them in a way that is fully understood by your procurement and management teams will create more realistic, deliverable, guidance-led solutions for your project. The due diligence exercise will require the supplier to involve production teams, alongside their salespeople in order to critically assess the practicalities of solutions defined and the true viability of those solutions against the organisation’s technological and resource capacity.

    1. Develop a contract that encourages delivery aligned to service requirements

Your contract should be a guidance tool, helping both sides to follow a pathway to a successful collaborative relationship. Yes, there will be elements of your contract that define resolution steps to issues faced and your contract needs to be clear and detailed enough to be used as evidence in any legal dispute you may find yourself in. However, its primary goal should be to guide and advise, to be a mutually agreed document that both sides find useful in relationship management. Because of this, some of the most successful contracts we have seen over the years have been reverse engineered from the business outcomes that have been agreed between the parties. If you know where you are going, you can build a roadmap to getting there and with this roadmap you can determine the steps you need to take to most confidently reach your destination.


The analysis by Public of six and a half years’ of assessments on these key initiatives, listed on GOV.UK, shows that there is still quite a way to go in the delivery of successful major IT projects. The fact that misunderstanding of user needs remains one of the key failure points is worrying, but it is reassuring that the standards remain high to push clients and suppliers to do more to ensure that every step along the way is given the attention it deserves.

Photo credit: iStock