Hi there!

Welcome to the latest (video)blog. In this post we will discuss budget overruns during the implementation of business management software, such as Enterprise Resource Planning systems or automated manufacturing management systems.

#9 Vlog on Next Level Jewelry with Zsolt Torok

Subscribe to our YouTube channel

I have been following Panorama Consulting for a while now as it is a reliable ERP consulting company. They do research amongst their own customers on a yearly basis and they publish these in the form of case studies that contain a lot of useful information, especially when it comes to mistakes and failures of every kind. I find these highly educational as one can learn a lot from these mistakes – sometimes more than from successes.

Budget overruns used to be the most common issues during the software projects.

Namely, research data shows that in 2017 over 65% percent of companies exceeded their implementation budget. This percentage was even higher in the previous year at 74%, so while it is an improvement, it is still staggering.

And this is happening with large companies, you know, the ones with a lot of resources, a lot of preparation and large implementation teams. For smaller companies these percentages are even higher as they can’t afford all the resources that need to go into planning and executing the implementation.

So why does this happen? Why can’t even large companies eliminate the uncertainity when it comes to bugeting? Does this happen because they don’t evaluate the necessary resources correctly? Are these somehow caused by communication issues between them and the software vendor? While these and a bunch of other issues are the usual suspects, there are a few uncertainty factors that cannot be foreseen at the time of establishing a budget  and signing the contract with the software vendor.

Business software implementation in the jewelry industry has the same issues as in other industries - the initial budget often just isn’t sufficient for the implementation. So why is this? How can you control budget overruns? And are there cases where this should not be considered a problem? Well, let’s see.

Why do we have budget overruns at smaller companies?

To answer this, let’s look at how implementation is done in most cases. At large companies the implementation process usually begins with a detailed evaluation of business requirements. This is a work-intensive process that can take months to complete. Once done, the requirements are reviewed by the software vendor, who then estimates the effort and provides and estimated cost – emphasis on “estimated”.

WhySince we’re talking about business management systems, we can’t really compare it to, let’s say, purchasing a Windows license, where you just purchase a new license and you are done. In the case of business management systems there several things that have fixed costs like licensing fees or hardware, while there are many others that can only be estimated – like necessary configuration and training time, integration fees, customization fees and so on.

These can only be estimated because there are too many factors that cannot be foreseen but can influence the final price: the technology changes, staff changes, there are  difficulties with integrating with third party software, human resource problems, and on and on and on.

These will all all affect the price of your implementation so it’s not a bad idea to have a buffer in your budgeting for these, because Murphy will be just around the corner, and if something bad can happen, it will happen.

Build the risk into your budget

7+1 risks you should pay attention

Now, let’s get into the details and go through the main risks one by one – and remember: the more complex your business, the more likely one of these will happen.

#1. Lack of detailed project requirements

Introducing a management system for large companies is often preceded by a prolonged planning period – the larger the company the more planning is needed. In this phase the goals are documented, as well as the path of achieving them, including the resources, infrastructure or human resources needed. In the case of small and mid-sized companies this works differently, for several reasons.

One of the reasons is that usually there’s no possibility of assigning a dedicated project team who will be working on the implementation. Small companies usually work with an outside consultant, or someone from the management is assigned to fulfil this role. Sometimes the operations manager or the owner will become the manager of the project because the company is so small that all information is centralized with this one person.

ListNow, this can be a problem and there are several risks that come with this. First of all, in most cases like this, there is no detailed requirements list as the owner/manager does not have time to really think through what’s needed and all the variables involved, so they only agree on the most important points with the vendor. So they may say something to the extent of: “we would like our management software to be integrated with our website” and that's the end of it. That sounds simple, but it raises surprisingly many questions if we start digging: do we need website orders to be synced directly with our system? Do we need to sync our inventory too? Do we need new customers to be entered in our system automatically? Where do we need to track order fulfilment? On the back-end of the website or in the business management software? What information do we need to sync back to the website? How do we communicate with the online customer?

And again, the questions just go on and on. As we can see, there are a lot of questions that aren’t clarified at the moment of finalizing the budget and signing the contract and because of this, the vendor cannot provide an accurate estimation that would cover the actual amount of work.

When chosing a business management system it is also a problem that the client typically doesn’t have a deep understanding of it and can't be sure that all the business needs can be properly covered by the software as is, withouth changes. Every software has limitations and there may be differences between what is needed and the actual functionality provided by the software.

We call this the Soft Delta, with a catpital D. This Soft Delta becomes obvious only during implementation, once all the requirements are properly uncovered, and this may result in some extra development work in order to customize the system and minimize the Delta. In extreme cases the client may step back from the project if they encounter a larger Delta than what can be bridged - this point to a careless selection of the business management system.

#2. Re-engineered processes

It is a frequent problem that the project manager leaves for a different position or different company and a new person is assigned as project manager with a whole different perspective and agenda. As the new project manager starts learning the software and the configuration, there is a good chance that they will see and think about the processes differently, leading to unplanned changes.

This can easily lead to lost time and money.

If 40 hours were estimated for the configuration of a project, but after 20 hours of work the implementation has to be started from the beginning, it is possible that completing the project will require an additional 20 hours in order to bring the new person up to speed and to accommodate his or her changes to the project. In this case the budget estimation in the initial contract won’t be valid anymore.

#3. Lack of testing and re-testing

It is possible that the manager of the project is being pressured for time and to speed up the configuration and go-live, and therefore doesn’t pay enough attention to testing before company-wide roll-out. This directly results in thinking that the given solution will work, but testingafter going live with the system we’ll find that the process is not time-efficient enough, requires too many human actions, some re-arranging of steps, and so on.

This is typically followed by some reconfiguration of the system, and even some extra development. Because neither the extra development, nor the reconfiguration was part of the contract, these will both generate additional costs - again, on the top of the initial budget estimate.

#4. New company objectives

It’s not uncommon that new requests, customizations are needed that were unknown for both parties at the time of signing the contract. For example, you may have a very specific business case that needs to be implemented before you can use the software.

This is what Change Requests or Change Orders are good for – the development or implementation rate for such change requests can be specified in the contract, but the actual costs will be defined on the go, once the requirements are known.

#5. Changing business environment

Although this is one of the least frequent issues, there can be cases where a jewelry business is acquired by another company during the implementation process, or there are significant changes in the regulatory environment. In cases like this significant adjustments may be necessary in order for the software to be suitable for the new set of circumstances.

It’s possible that changes have to be made to the inventory configuration, or entirely new work processes need be introduced. If this happens you will definitely need extra configuration and development time compared to what’s estimated in your original estimnate.

#6. Your hardware doesn’t prove to be up-to-date

This is important when you want to host the software yourself, on your own servers. It is possible that you need to acquisition new hardware resources in order to provide a good functioning environment for the software. This may not be obvious during the implementation because the system is only used by 2-3 user, but under live circumstances this number can multiply and if the infrastructure is not adequate, this can result in slowness and the cumbersome use of the system.

You should always ask for the vendor’s suggestions regarding optimal hardware requirements before deciding to host any business software yourself.

#7. Data migration

I have mentioned it in my previous videos as well, that we often underestimate the significance and time demand of data migration. At the time of signing the contract the vendor has little insight on the quality of data they will be working with, therefore no matter how much the estimate, there will almost always be data cleaning and data migration difficulties which won’t always will be assumed by the vendor, or even if they are, they will mean additional costs.

+1. You negotiated too much of a discount

Yes, that means to you paid too little and that gets you in a whole pile of problems by itself. It’s within the human nature to haggle, therefore you may try to get the best deal on jewelry software as well.

Many software vendors are willing to give some discounts as they are looking to get new clients, but this is in most cases not beneficial for the outcome of the project. If you pay too little, the vendor may focus on the customers that paid a higher price and put discounted clients on the backburner, and on the other hand, they will be less inclined to do small “favors” or agree to changes - they may even be slow in implementing the changes they agree to.

In extreme cases a vendor may even step back from the project, because a non-profitable project is an unwanted burden that they want to get rid of. And that is clearly a lose-lose situation that needs to be avoided at all costs

What solutions would I suggest that can help reduce the risk of budget overruns?

#1. As a first step I would suggest trying to prepare a requirement list as detailed as possible. Document what you’d like to haveChecklist and don’t be satisfied with thinking that you know know all the details or that a problem has a simple solution - for most problems that is certainly not the case. It is worth putting this list aside and revisiting it in a few weeks’ time – there always will be a few things which you haven’t thought of before. It is worth, and in fact we encourage asking employees’ and key users’ opinion, as they will certainly have ideas that should be added to the requirements.

PM#2. Assign a project manager or sign up with a consultant who has the necessary professional experience, and who understands the requirements – they may even help preparing the documentation, chosing the ERP and they will represent the interests of your company throughout the implementation.

#3. When choosing a business software or ERP package, don’t decide based on just a short demo. Convince yourself that the system has at least 80% of what you really need. After the demo write a list of your questions and send them to the vendor. Ask for a second demo. Ask for a demo where the vendor will show you a few solutions to problems that are specific to your business. For example, ask them to create your own products or your processes in the system as test data - this way it’ll be easier for you to understand how the system can handle the practical functioning of your business.

#4. Ask the vendor to specify in their proposal what kind customizations they include, how much change requests cost, what procedures they will follow in the event of unforeseen changes.

#5. In case of larger, more complex companies there is another solution that may greatly reduce the risk. This is the so-called evaluation phase. In this case the two parties may sign up for an evaluation project prior to the actual implementation. In practice the vendor will prepare a mock-up configuration for the client for a fee, which they will test together, uncovering the Soft Delta I mentioned earlier. Following this testing they will prepare a detailed list that has all the requirements and the necessary customizations and extra development works as well, thereby minimizing the Delta. This type of evaluation has costs involved, but it greatly reduces the occurrence of unpleasant surprises for both parties during the implementation and thus it will dramatically reduce the chances for of failure.

Summary

As I mentioned, these are all assumptions based on real situations and reasons. If we look at things from this point of view,

a 20% reserve budget is an extremely important part of the planning process.

BufferI say this especially to those who are preparing to introduce a jewelry software for the first time, since they have little relevant experience in this matter. But the main message is that when choosing a software, don’t focus on its price, but put more emphasis on the potential it has.

I would also like to add that you should try not to save on your budget as that may work against you, but rather consider savings and benefits that the software can bring you on the long run, as these would have a much bigger impact on the company than saving a few thousand dollars on implementation costs.

Subscribe me to the Next Level Jewelry YouTube channel

If you have any relevant experience or thoughts in this topic, please share them in comments below.

How to get started?

Explore PIRO and see for yourself how it can benefit your business.
Schedule a free online demo now!

Click here to request a free demo