How to burn money in projects and get poor outcomes

According to David Withers APP, there are plenty of reasons why projects fail, and these failures can result in objectives not being met and stressful work environments that result in staff churn.

David Withers APP is a Security Consultant with experience in large CCTV installations. He has also worked for over 20 years in Quality Assurance It does not matter if the project is a civil project, CCTV and security, or software, projects often fail – or under-deliver – for organisations.

As a general consultant, I get to work on a wide array of projects and observe what works and what does not. From what I’ve seen, there is often a cluster of undesirable situations that cause these failures. Let’s look at some of them.

Too many chiefs, not a lot of progress

Poorly focused projects with too many chiefs are often out of control. They are busy projects that consume resources for very little benefit. The actual delivery teams are overwhelmed by divergent and frequently changing requirements.

All this does is creates stress, friction, confusion, and delays in the project. In some cases, it results in you losing key valuable team members due to stress and frustration at the exact moment you need them.

Forgetting about use cases

A grand project vision a great way to get investment in a project. This needs to be converted into a realistic deliverable. Solid use cases based on value to the organisation help guide the delivery team in choosing the right technology solutions and treatments.

Use cases help project teams focus on delivering a solution that delivers what the organisation needs and gives the most value to. This enables the selection of the correct technology solutions, security treatments and infrastructure that deliver what is required.

Often, no amount of adjusting or tweaking can fix an incorrect choice to get the desired results. These can add unnecessary costs and friction to your business. An example could be an IT team delivering off-the-shelf Microsoft products for reporting to save budget rather than an enterprise reporting solution. In the security space, this could involve the installation of incorrect technology that cannot perform the required tasks.

This applies to all projects. Good use cases help us focus on the valueadd propositions, focusing resources to deliver better and faster solutions, and often freeing resources quicker for other projects

Playing it safe: using trusted go-to people

Using familiar suppliers rather than going to market to get the right solution can end up delivering the wrong solution. It’s all too easy to rely on old trusted networks and suppliers to solve our organisational needs. Whilst this can assist in quick solutions due to low friction, is it necessarily the right solution? Do your suppliers have the most relevant solutions for your needs?

If your organisation has a new requirement, it’s better to fill it via the open market. Worldwide markets and technology solutions are moving faster and faster, with organisations needing to change to survive. Existing suppliers may not have the best solutions for our current needs.

Are you following your own vision or your competitors’?

Are you following your competition or following your own destiny? Is your project delivering something in order to chase your competition? If so, you really need to question whether it is adding value to your business and is aligned with your business plans.

It is all too easy to chase your competition and not gain best value from the investment and project resources. These projects often divert resources from projects that could be used to differentiate your organisation from the rest. It is important to invest resources in projects that drive the business towards its aims and vision.

I just want that toy; make it so

My personal favourite: the senior executive who’s just been to a conference and saw this awesome technology and must have it. They will not let the fact that it’s expensive, has no strategic benefits, and is not compatible with existing systems get in the way of implementing it.

These projects can consume vast project and operational resources and are often maintenance-heavy once operational. They can be a big distraction and take resources from more important projects.

Putting a square peg in round hole

Some systems are not compatible. A classic example is Apple versus Microsoft: they do the same thing, but software cannot be shared between them. Implementing software or solutions that are not compatible with the technology stack in your organisation is an endeavour that’s doomed to fail. You are better off finding an alternative that is compatible.

Thinking too small and doing it twice

We often see companies choose to invest too much in small proofs of concept and try to operationalise them, only realise they are not fit for purpose. They then must do a second project to do it right.

POCs have their place, but if you are planning on keeping a system, it is important you invest sufficient

Shooting for the stars and burning out

These projects frequently have grandiose names like ‘Project Mars’ and aim to solve all the organisation’s needs in one go. This approach often results in project failures, with organisations ending up with nothing to show from significant investments.

Normally, such projects aim at doing too much and they run out of money before delivering anything of value. As with the ‘thinking too small’ problem, you often end up having to invest in additional projects to get the results you actually need.

Running before you can walk

Being realistic about the size of you organisation and technical ability is important. Smaller organisations with a basic technology stack sometimes attempt to install advanced solutions despite lacking the technical resources to install and maintain them. This results in project failure and little to show from the investment.

In summary

The situations above don’t seem too serious in in themselves. But, sadly, we often see these come in clusters – for example, an organisation embarking on a project with ‘too many chiefs’ and ‘overly grand plans’.

An important consideration in relation to these situations is how they affect your people. The organisations I observed in these situations had very high employee churn rates. One client lost 90 percent of its IT department due to much business interference causing stress on the team.

Even if you don’t lose people, team members in projects with the above problems are often not happy and highly stressed. It creates an adverse working environment for everyone, which is not productive.

No organisation has unlimited resources. Having right-sized projects that deliver against actual business needs can go some way to avoiding the occurrence of the above situations.