7 reasons digital projects fail (and how you can turn them around)

1. Diluted objectives & losing sight of the why

Maybe you had a clear business goal at the beginning but it has not been well understood by the team delivering. Perhaps the goal was never clearly articulated. Changing market conditions, a change of leadership or commercial pressures can all lead to a project team losing focus on its original aims. Unfocussed teams get bogged down in trying to execute too many ideas at once, or in circular discussions about the merits of a feature or approach.  

Solution: refocus the team

Take a deep breath and pause work on your project. Gather the whole team and hold a workshop session to revisit - and if necessary, reposition - the original objectives of the project. Document the lessons learned so far, and any changes the team wants to take forward. You'll need to bring a solid understanding of the wider business strategy, and a good dose of objectivity. Once you have settled on the objective you will need to solicit buy in from stakeholders from delivery team right up to senior leadership, but once everyone understands the shared aim, you should be back on track.

2. Stretched resources & skills gaps 

It’s common across a range of industries to find teams trying to deliver on multiple transformation projects, at the same time as providing support for existing products or services. Inhouse teams in particular can feel the impact of this, where social pressure from inside the organisation, or short term 'urgent' tasks disrupt the ability to focus on a complex project.

This can leave your team burned out, stressed out and demoralised. There may also be specific, specialist skills required for a particular task or feature, that the team does not have strong competency in and this can slow down the project or impact quality.

Solution: Partner with an external agency in blended squads.

Usually it's not an option to increase a team permanently, and contractors can be expensive and increase the management overhead on your already stretched team. Partnering with an external digital agency is a great way to flex your resources to match the shape of a project, or to ringfence resources for a specific objective - it's harder for internal stakeholders to reach a third party developer with distracting tasks, and the external team will have access to a range of project management, design and engineering skills to support the project where needed.

3. Technology distractions

Sometimes a project loses sight of its business purpose, (see also point one above) and becomes too technology driven. It's tempting to try to incorporate the latest technique, language or architecture to your project. The team can deep dive and geek out on the shiniest thing, innovation takes precedence over usefulness.  However tempting this is, regularly bring the team's attention back to the why - how is this related to delivering the project objective? Do the key audiences care about this feature? Platform and tech should be the last decision in the chain - after the what and the why comes the how.

Solution: Bring in real users to provide feedback

Similar to losing sight of the objectives, a project that has succumbed to shiny object syndrome will need a reset. Gather your team, and any material from the project's discovery phase. Who are your users? What are their drivers as defined in personas? If you didn't develop user personas or mindsets at the beginning of the project, do that now. Figure out what your project is supposed to deliver, and who for, and use that to steer the best fit technology to solve the problem. Even better if you can have real user focus groups to review your plans and test a prototype or Beta version.

4. Over-ambitious expectations & in-project scope creep

Did you set out to digitise a specific part of your service, but now you seem to be rebuilding every process in the company?

Some projects start out as a giant wish list with an unrealistic time frame applied. Ideally, that would be identified in the early stages, but we have all been caught out by optimism and enthusiasm at some stage.

Even when an initial scope is sensible and well defined, scope creep is a real risk in every project - every project team we have ever worked with has more good ideas than can be delivered in the first iteration, and as you get started building, more ideas will emerge. As a project grows in scope it can start to feel unwieldy, there are multiple threads to keep track of (which pieces are in development? Which pieces are done?) and there are more interdependencies to test as you go.

Solution: Strict definition of delivery iterations

Whether or not your team is working in an Agile methodology, it can be useful to define an MVP version - remember it stands for Minimum Viable Product, not 'Minimum amount I wish I could deliver if time and money were no object…!'. A tightly defined MVP will allow your team to complete a project and get it out into the world - the team gets to see tangible results, the business will start to see a return on the investment earlier and the insight forged from real-life use will undoubtedly shape a stronger next iteration.

 5. Actual technical incompetence

This one is less common, but it does happen. You may inherit a project that has been partially completed by a team that the organization has lost trust in. This could be an internal team or an external partner. Often it’s hard to see the poor workmanship in a digital product without a high level of technical understanding and that can leave project leaders with active paranoia about the quality of an inherited project.

Solution: technical audit and code review

When inheriting a partially-completed project, the first action should always be to run a formal technical audit. Reviewing the audit report allows the team to create a baseline from which expectations can be set for the remainder of the project. The audit should be completed by an expert team and include a review of the platform, architecture, and source code from the point of view of performance, suitability and security. Once the project has a clear technical baseline defined, work can continue on the project, incorporating any adjustments that are needed to the work completed so far.

6. Blindly following a project management methodology

One could (and people do) spend an entire career exploring and mastering the intricacies of project/product delivery methodologies, like Agile/Scrum, Prince II, Six Sigma… Each originates in a different space (software, IT services, manufacturing) and has its strengths… but the one thing they all have in common is that they're useless in these common scenarios:

• If the team are completing steps because a methodology says so without understanding why
• If the team do not have shared buy-in to the methodology they are following
• If the methodology is too complicated (or too simple) for the nature of the project
• If the methodology is at odds with the style and structure of the business

Teams often have challenges implementing Agile Scrum based projects in highly regulated or very traditional businesses, where management may not be used to the flexibility and feedback required. A Waterfall based project management style might mean that a development with a lot of unknowns gets bogged down in the specification stage.

Solution: Hire a coach

This could be an internal person in the business but outside the project, or an external consultant. The idea is to bring in a third party who is expert in the methodology, and who can act as a mentor to the Lead or as a facilitator to make sure project updates are completed correctly and effectively.

7. …or NOT following a methodology at all

Over-rigid adherence to process methodologies can mean time wasting debating if you need to actually be standing up to hold a stand-up and arguing over story points, but  having little or no project discipline can be just as problematic.

It may be tempting to run smaller projects with a 'seat of your pants' approach and to depend on the quality of your people to pull it off. After all, you have a great team! You have a good track record! It was fine last time!

However projects without enough formal definition and control can come unstuck quickly, at best needing a heroic effort from the team to save, and at worst leaving you with a busted budget, late delivery and a disengaged team.

In our experience, it’s the smallest, simplest projects that have the least room for corner cutting - after all a couple of days of inefficiency have a larger impact when the overall budget or timeline is smaller.

At the very least, all projects need an agreed objective and list of deliverables with dates associated with them.

Solution: pause and take stock

Retrospectively add in some project discipline. Review where you are versus the agreed deliverables, and make a project plan to get you from here to there. Communicate the new plan with the team and stakeholders. It might be tempting to keep your head down and push through. But stop and set yourself up for course correction as soon as you can.

Whether you have a digital delivery going wrong or are looking for someone to adopt and complete a project for some other reason, chat to the team at Shout about whether we can help you.