24 July 2018

5 Critical Signs That Your Digital Project Is Headed For Failure.

I’ve been around digital for a long time. I’ve seen some unbelievable situations unfold with client projects. Thankfully nothing so bad that it has ever sunk a client's business or an agency. But I've seen the toll it can take on people managing a project and the fallout on clients who have been forced to move on from a failed project. Project failures happen, and within digital development, it is a particularly common problem. Picking up the pieces from a failed project is far more expensive than just getting it right in the first place. But that is easier said than done. There are dozens if not hundreds of moving parts that are a consideration for any digital development.

My experience: In my 15 years, I have been a part of a number of project retrospectives that backtracked failure to a specific decision, a problem with communication, lack of process, or mismatch of expectations. Here are the most common issues that I have seen as the cause of project failure:

  1. The project was started too quickly (predictive measure)

  2. There wasn't a single detailed source of truth regarding the project scope (predictive measure)

  3. Project bugs that were reported are not fixed on review (symptomatic measure)

  4. The agency doesn’t know how much longer development will take (symptomatic measure)

  5. Your agency goes radio silent (symptomatic measure)

Worst Case Scenario: The Queensland Government leads the way with the spectacular failure of their Healthcare Payroll System at the hands of IBM. For a $6 million dollar budget, the project came out at $1.2 billion budget. This could be classed as one of the world's worst system development projects. I was surprised it wasn't listed on Wikipedia's page for worst project overruns. So I added it myself: https://en.wikipedia.org/wiki/List_of_failed_and_overbudget_custom_software_projects

The issues identified above are split between predictive and symptomatic measures.

  • Predictive measures represent issues that you can avoid so long as you follow standard industry practice.

  • Symptomatic measures are alarm bells that you need to be watching for. These are problems where you will need to step in and urgently take corrective actions in order to put your project back in its tracks.

1. You started the project too quickly

More than 50% of the companies that come to us would like a solution 'yesterday'. This is understandable, business is a fast-moving animal and to be slow is to risk losing out to your competitor. With the pressure on, the intuitive response is to demand action as quickly as possible. Where you can ideally see something tangible produced to gain comfort that progress is being made. However, starting quickly has the following consequences.

  • Important details may not be properly considered.

  • The project is not properly costed out. Leading to an insufficient budget for the project.

  • The process is skipped in order to start quickly.

  • External dependencies are not factored into planning.

  • Risk management is not considered.

Process adds time and cost to projects, but decreases long-term cost, conflict, and project risk.

Starting a project too quickly is the root cause of many if not most project failures. The better the planning for a project, the smoother the project will be. I believe that the slower the project starts, the faster the project will end. In the absence of proper planning, you push your problem-solving into the body of the project, slowing its velocity at a time when you want to it be coasting along. Things to consider:

  • Resist the temptation to push your development project into active production quickly. Consider your timeline, what is driving these demands?

  • Consider whether you are pushing the agency to show something (potentially fake progress) over real project progress?

  • Ask your agency - have you been given a best-case or a realistic schedule? Are there contingencies factored into the project schedule?

  • Is it clear who has responsibility for all components of the solution? (common issues, content entry, integration, vendor coordination)

What is driving your timeline? (Thinking outside the box)

What does the timeline for your project represent? Do you actually need to complete everything for the project upfront? Is the timeline provided by a higher level staff member, purely to fit within an artificial planning horizon or is this a real unmovable launch date? If the timeline is artificial, buy your project more time and highlight the risk of forcing a date on a project. The stress of challenging an internal timeline up front is nothing compared to the stress of what happens if you don't, and you now have management breathing down your neck as to why a project is behind schedule or profoundly broken. If timelines are fixed, you could consider:

  • A staged approach

  • Talk to your project owners about their key priorities, and eliminate anything not critical. Be brutal

  • A tease campaign release/campaign, like a landing page with database capture.

  • If it's an industry event, you could demo designs or a prototype, use the future release as an opportunity to create a reason to capture their details and follow them up)

Example: We were working with a company that was launching in the US. They have a timeline of a month for complete e-commerce build to be ready for the launch. After talking to the client, it was ultimately discovered that they wouldn't even have the people on the ground ready to be able to support an e-commerce solution if it was made. With this information, we instead recommended the creation of a campaign launch page that announced the company’s imminent arrival in the US. If the user provided their details they would be notified when the store would be available with a launch discount on a one-time product. This was a completely acceptable, if not preferred, option for the client.

2. You have no single source of truth for scope

A single definition of project scope is a critical success factor for any digital project. During the conception of a project, there will be lots of conversations, meetings, phone calls, and emails. If these are not brought together in a comprehensive scope of works (or functional specification) you leave yourself open to something being missed. What happens if you don't have a strong scope? You end up getting to a point in the project where you ask where the thing you wanted is, only for the agency to say that it is not in scope. You then fall back on your recollection of conversations in meetings, early-stage proposal documents, and old emails to assist in deciding what is, and is not in scope. This is a bad position to be in and results in at least one party not being happy. You may be able to push the argument if your agency has weak processes.

But an organised agency will make sure it is very clear that the scope is detailed, and the work to be completed is as what is documented. They may also say that while the request was raised, it was removed from scope due to cost or time pressures. The difficulty with scope definition is that unless you have deep experience in digital project management, you may not know what a good project scope definition looks like. Good agencies will place as much detail and clarity in their statement of works as possible. In our experience, we have found in spite of the work we put into documents to make the scope clear, some clients do not properly take the time to read through the documentation. We do recommend that you take the time to review your project documentation and to ask questions if something is not clear.

What you can do


  • Potential Issue: You may have discussed an important feature within a meeting.

  • How to prevent: Schedule time to review scoping documents from the client. It may be useful to sit down with the agency to work through this line by line.


  • Potential Issue: You assumed that something would be managed by the agency, or they assumed you would be doing something

  • How to prevent: If you have prepared a brief, and you are signing off on a statement of works. Print out a copy of your brief and tick off each element you need to be included in the final document. The agency will have the position that if it's not in the scope, it won't be done.


  • Potential Issue: It can be difficult to identify what is not included in a list of items than to identify what should not.

  • How to prevent: Take notes from your scoping meetings, and email any key points back to the agency. Identifying correct and incorrect inclusions is easy, what you want to do is identify commissions.


"The missing detail"

About 5 years ago I was working in the industry when I heard about a project as it was going off the rails, it was for a major Queensland institution. The agency was developing an app for an event. Being an event, the application was time-critical, and there was a drop-dead date for completion.

The app wasn't ready on the delivery date and the project managers promised delivery the next morning. For every hour of the next day, the project manager said the application would be ready by the next hour. Shockingly, this same hourly call happened 8 times the next day. Eventually, it did come through a few days later after someone stepped in and suggested the 1-hour planning horizon was a disastrous way to manage the client's confidence. The missing detail? - The critical detail lost in rushing into the project? In order for the application to work, it required a second application mapping to be installed. A hugely jarring complication to the user journey. At no point during the project was it highlighted or documented that this would be the solution.

3. The reported project bugs are not fixed on review

This is a profound issue that demonstrates a serious issue with the agency’s quality control mechanisms. There is no practical way to prevent this, other than to ask your agency what their quality control measures are at the start of the engagement. But still, talking the talk is easier than walking the talk. The complexity with digital is that it is heavily interconnected. Fixing a problem in one place can create a problem somewhere else. This happens, but you don't want to be playing whack-a-mole. Should this problem repeatedly happen, this is indicating a worst-case scenario for your project - in order to make sure that you receive a properly constructed system you are going to have to perform a complete system test on every single release of the website. This is a profoundly time-consuming activity, and I hope you don't have anything better to do. What you can do:

  • Suggest your agency get an independent staff member to check the work

  • Ensure there is a consolidated centrally managed list of bugs, email is the worst place to be managing bug lists

4. Your agency goes quiet

There is a period of time when your agency won't have much to say to you because they have stuff going on internally with your project. Such as when primary development starts, everything has been set up and now things need to get done. But if you are near the end of the project, and you have already had a few rounds of testing and communication has slowed to a trickle, this is a huge warning sign. This usually means the agency is in trouble. Either the project is over budget internally, or they have no idea how much longer the project will take. The agency potentially may have put your project on hold in order to get through other work for cash flow. Working on a large over-budget project in a smaller agency can be suicide. Once a project goes over budget at an agency, this starts to crash the rest of their production and cash flow. The worst thing about this situation is that you have no idea what is going on. And have no capacity to manage the situation. This also means you are about to spend a whole lot more time managing the agency and vetting what they are producing. How to correct this situation:

  • Push your agency to provide some kind of timeline for completion, a realistic one. If it looks like they aren't going to hit the timeline, make sure they tell you as soon as that looks like a possibility.

  • Suggest your agency provide periodic updates, regardless of perceived progression.

5. The agency doesn't know how much longer development will take

Any agency with any degree of experience knows how to scope, quantity and map out the effort required to complete a project. So, if your queries of timeline are met with a shrug, this is a black flag and requires an immediate intervention as your agency has lost control of their ability to manage the project.

What you can do

You will need to get your agency to stop and take stock of everything that is yet to be completed, with an estimate on how much longer these tasks will take. They will need to be encouraged to be as realistic as possible about their estimates. There will be a tendency to try and play down the problem, rather than having an extremely awkward conversation about how bad things actually are. 

Bottom line - Be careful who you choose

These are problems that I have seen in my time, but there’s no guarantee this will happen to you. Choosing an agency with a proven history of delivery can eliminate a lot of the risk of dealing with toxic projects. It can be a profoundly stressful situation to be caught in a bad project that inevitably can make you look bad, even if you are not at fault. Use our advice to try and make sure you get your project off on the right foot, and if you see the warning signs, be sure to act promptly.

Want to know more?

If you would like to talk to us about this article, digital project management and the results we could achieve for you, get in touch at greg@lamb.com.au or check us out at http://www.lamb.com.au

About Lamb Agency

Lamb Agency is an industry-leading provider of digital solutions. We have worked on many complicated digital projects for companies like Lite n Easy, Virgin Australia, National Storage, and Dominos Pizza.

Greg Nelson

Greg is the Managing Director of Lamb Agency, a digital agency focused on creating industry-leading websites.

Talk to us.

Talk to us.