How not to: Three risk factors of an IT implementation project

Blog: How not to: Three risk factors of an IT implementation project | Boltrics

How not to: Three risk factors of an IT implementation project

With our blogs, webinars, videos and other content, we want to share relevant information with you. For example why Cycle Counting might be interesting for you. Or by giving more in-depth information about the KPI occupancy rate. But until now, we never told you what you should not do. On the one hand this makes sense, because telling you what not to do for every separate subject would take a long time. On the other hand it does makes sense, because warnings usually start with “don’t”. “Don’t cross the street without looking left and right first”. “Don’t touch the cookie jar, or you will be in trouble”. And don’t get me started about the Law. This is why I present you Boltrics’ first “how not to”. In this edition I will mention the risks of an implementation project.

The danger of an ill-considered implementation project

There is no doubt that you know a story about a company where an implementation project failed. Followed by dealing with the loss and saying goodbye to the promising software of the helpful automation consultant. These type of messages are hurtful to read and we feel sorry for all the participants. Last year for example, a German supermarket brand lost 500 million euros. No one will call a half a billion loss “Lidl”, even the richest on the planet will not. The reason? A project approach that did not match the set goals.

The most common risk factors of an unsuccessful IT project

How is it possible that it goes wrong on such a major scale in these situations? That a customer and its supplier eventually turn their backs to each other? With the result of accepting astronomical losses? This made me think and I got to three most common risk factors of an unsuccessful IT project.

Not enough time and insufficient time management

According to ERP trade journals, implementing a new ERP system costs a lot of time. And this time usually is not spent correctly. For example, not enough emphasis is laid on key-users and training the end-users. If everything is not fixed on the customer side, working towards a successful go-live is almost impossible. The system may be adjusted to the initial request. But if the ones that will be using the solution do not now how to use it, delivering it is useless. Because it does not solve anything.

A scope that is too wide

A trajectory is defined by a start- and an end point. Whether it is an IT trajectory or the trajectory from London to New York. The start point is usually clear. Unfortunately, the end point is too often not clearly defined. Because of this, automation consultants are trying to hit a moving target. Halfway the assignment something is added or another thing needs to be tweaked. This way, the scope continuously changes. As if New York suddenly moves to China when you are flying over the Atlantic Ocean. Obviously, this will not work. Only when the scope is clear for all the parties involved and the phasing is planned out, working seriously on a project from beginning to end is possible.

No optimization or maintenance after go-live

In many cases, an IT trajectory needs hard working. A lot of consultation, many resources that need to be available and lots of thinking. This often results in companies and its employees not having enough strength after the intensive implementation period. Or they need to move on with another project, and therefore do not have enough time for optimization and maintenance for example. And most of the time, this is where the difference is made between success or no success. Earlier, Remco called testing the key to success. Testing, optimizing, testing, maintaining. This way you will not run into unforeseen problems and you can work with confidence after the go-live.

Check, shake and sign

At Boltrics, we are well aware of all the beforementioned risks. Even so, we still guarantee our customers they will be live within 90 days with their primary processes. This is possible because we set the scope clearly and we pin this down in our agreement. When the implementation trajectory is succeeded and the customer is live, we will go towards delivery. At that point, we check if the set goals are reached. Is this the case? Then we shake each other’s hand and we both sign for delivery. Most of the times combined with a nice piece of cake. This is what we call the check, shake and sign method.

Blog: How not to: Three risk factors of an IT implementation project | Boltrics

Aftercare after implementation

After delivering your implementation we are not done yet. A Customer Success Consultant is assigned to you. He will help you realize your optimizations and thinks along with your company. Also, our software is always up-to-date. This means that you always have access to the latest functionalities after each periodic functional update. Why is this relevant in this context? Because this way of working makes panic, sprinting or finishing up unnecessary. Your work environment is changing, your work is changing, your company changes along and the same goes for our software.

Boltrics’ proven approach

The approach that we developed through experience showed to be proven by working for small, medium and even big companies. If you want to know how we do this, you can read it in Patrick’s blog. If you want to know how we can do this for you? There is only one way to find out.

Posted by
Frans Kurvers

Partner Manager at Boltrics