Why App Development Projects Fail

hammer and smartphone with smashed display

HOW CAN YOU AVOID APP DEVELOPMENT FAILURE?

 

When you’re working with an external app development team there are pretty much three reasons why an app project can fail:

  • Incorrect budget
  • Inexperienced developers
  • Poor project management

Let’s start with the last one.

 

Poor Project Management

Never use a developer whose project managers aren’t qualified in at least one of the key project management methodologies, like Agile or Prince2. Always make sure the developer has a clear project plan and if you are still at the pre-contract stage before the developer will have produced one, ask to see an example from another project.

A project plan is the absolute heart of a project. It may shift occasionally to meet with unexpected events, like design assets not being approved on time, but the rule is once the project plan is in place it should be followed.

The single biggest cause of issues for ourselves as developers is when a third party steps outside of the project plan, either by not hitting agreed deliverables for things like copy delivery or testing, or by insisting we use their own processes to deliver the project.

 

The Inexperienced Developer

Let’s not lay all the blame on third-party interference. Often it is the developer themselves who gets it wrong, most commonly by underestimating a task. This can understandably happen when they have never built a particular type of app before.

To mitigate against this, either seek out developers who have built apps like yours already, or get a number of quotes (you should do this anyway) and if your favoured developer seems to be way off the quote estimate of the others, don’t rejoice in their mistake but tell them you are concerned and why. There will be a reason why you like that team – don’t sour a possibly great relationship in the long term by knowingly getting them to do the work in less time than you know it should be done.

Which brings us to the last reason:

 

Incorrect budget

After process failure, an incorrect budget (sometimes the developer’s own fault by under-estimating in the first place*) will lead to the greatest chance of failure. In fact time and money are pretty much the same thing to a developer as when they work out an app budget both are directly related to how much time is needed to undertake the project.

But what if the developer has got its time estimates right and you either don’t want to pay that budget or simply can’t? In the second scenario either don’t do the project or go get a more realistic budget. If you sit in the first camp then let’s talk about a very simple business logic, called the ‘value seesaw’.

In the value seesaw, often a developer wants to do as little work for as much reward as possible. That way, he thinks he’s on top. Conversely, many clients/customers naturally want to get as much as work as possible for as little money as possible.

Why is that natural? In both cases, someone loses out… For a successful project you need to deploy the value seesaw: an equal balance where the developer does the correct amount of work that provides value to the customer and the customer pays the accurate value of the developer’s work.

This pretty much applies to everything in business, but it especially applies to the way we want to do business with you.

If you have already experienced app development failure and you need a team to put things right then come and talk to us. We have rescued many projects for clients stuck with inexperienced or unethical developers.

We’ll take you through the extraction process, draw up the specification the project needed in the first place, where possible work with the code already built and where that’s not possible start again. All within an agreed timing plan.

* Unfortunately there are some unscrupulous developers who will deliberately under-estimate a project, in order to win the business. Once the project is underway and it’s too late for you to pull out, they will start to renegotiate the cost using a range of techniques, such as pointing out functionality that wasn’t included in the original specification (which they will have known all along was needed). There is little you can do about this, unless of course their quotation was much cheaper than other developers, in which case you were given a strong indication that the price quoted wasn’t right.

 

HOW CAN WE HELP?