Something went wrong: the reasons why internal automation projects failed

Interior automation projects are like furnishing the house you live in. It doesn’t matter if you do it yourself or with the help of contractors. Whatever you end up with, it will all be yours and you’ll have to live with it…or rather work with it.

Like any project, the goal of internal automation is to improve business operations. Unfortunately, my experience as a business analyst tells me that this is not always achieved. At least from the first iteration. Let’s explore what causes internal automation projects to fail and how to avoid them.

Reasons why internal automation projects fail
Lack of planning and poor preparation

The planning and preparation phase is very important for any project. In fact, it is its foundation which determines to what extent all further work will be stable and in accordance with business requirements. However, in an effort to move as quickly as possible directly to the implementation, planning is often neglected. And this leads to problems such as:

Unconvincing reasons for making a decision about automation

It seems absurd, but it’s true. With automation being expensive, management makes the decision based on their “want” or “because others have done it, why are we worse?!” And it’s not just young companies that suffer from this.

Here’s an example from my own practice.

I worked at a very large company, whose management decided that we needed to make our own messenger for internal communications. They did not like the fact that employees were using different communicators, so they tried to get everyone into one, which failed, and decided that a corporate messenger would remedy the situation.

In other words, the employees did not want to use the same messenger service for sending messages and making video calls, so let’s try to make something similar, and then they will use it. Of course, we were flattered to compete with Telegram, Skype, and WhatsApp, but it was just unclear why? And it would have been very expensive to finance such a project. In fact, this is what saved us from a pointless job. But not everyone is so lucky.

“Blurred” and unrealistic goals

A project without a goal is a waste of time and money. I think few people would disagree with that. But what counts as a goal? When we talk about automation projects, the goal should be to add some value. But not abstract, but quite measurable. Because it makes no sense to talk about efficiency if it is not supported by measurable quantitative and qualitative indicators. Yes, this is about KPIs. And in the future, when the project is implemented, it will be on the basis of KPIs that it will be possible to assess the degree to which the goals have been reached and the effectiveness of the project as a whole.

Ignoring or neglecting risks

No business exists in isolation, it is always affected by factors of external and internal environment. This impact can have both positive and negative effects.

The probability that these or those factors will entail the occurrence of negative events – these are the risks.

Usually everyone is well aware that anything can happen, but few people take a systematic approach to risks: they forecast, assess the probability of their occurrence and the degree of their impact on the business, and, most importantly, prepare scenarios for the development of events in case they occur.

It is always a great practice for businesses to do such exercises. But it is equally important to forecast and assess risks for specific projects. After all, in this case, the project will be insured against many unpleasant surprises that can affect its outcome not for the better. And the effect of their occurrence can be leveled.

Lack of resources and unrealistic deadlines

Let’s start with what are resources in terms of the project? First of all, it is a budget, of course.

The specialists, the people who will implement the project. And time.

Practice shows that projects often suffer from a lack of resources. I have seen some projects stopped for lack of budget. Then they were restarted. But it is not so easy to just pick up and continue the automation project after downtime – you need to assess what changes have occurred in the meantime, adjust plans and re-engage in the process.

Another common problem: in order to save the budget, they try to do with a minimum number of specialists. I once worked on a project where almost every team member combined several roles that were not his own. Of course, because of this the quality suffered. But in time to attract specialized professionals, alas, we were not allowed.

In addition to reducing the budget of the project, they often try to minimize the time. But to make a certain amount of work faster and cheaper is only possible within a limited scope. If you try not to pay attention to it, the quality will inevitably suffer.

Therefore, resource planning is a very important stage of project preparation. And it should be approached with all objectivity and seriousness.