10 Reasons Why Your New It System Implementation Failed

You have carefully chosen a Commercial Of-The-Shelf software and have been recommended a golden partner for implementation. Your new system is an enterprise solution, it covers all the areas of your current business and whatever you can scale to within five years. Your industry uses it often. The free GAP/FIT analysis performed by your vendor’s partner on your staff wish list went well and the discount on the operating systems is great. Have you seen such projects fail a lot?

Have you ever experienced such a well-prepared project exceed both the budget and schedule, and sometimes also fail to complete?

Whenever you are considering an ERP, CRM, Workflow or BI system, or a custom IT solution – make sure you don’t follow these ten reasons to fail.

1. You haven’t established measurable goals

The times when investments in an IT system were a cinch are long gone. Nowadays, change is driven by a business change and it needs to support the case. You need to establish a measurable business goal to achieve – other than the number of implemented systems.

It is a very good practice to coordinate business and IT change as modern solutions can very efficiently support business activities. Some good goals are:

• To decrease the costs of customer support by 5% through implementing new support channels and supporting agents with customer info and problem solutions knowledge base.
• To increase the returning-customer-rate and revenue-per-customer by generating new leads from previous sales history.
• To lower the cost of purchase by 10% through implementation of electronic auctions for significant orders.

Such goals will provide you and your team with a clear direction and will be of great help for the implementation process. Make sure to share them with your solution supplier so you know everybody has clear understanding of the goals and everybody is on the same page. You should work out ways to collaborate towards these goals together, and in order to do that, you need to get everyone to understand what the goals are and why they’re like that.

2. You haven’t let your employees define the requirements

You often hear that the user, the customer, and their experience are very important, that they need to have an impact on their software and that it should meet their expectations. As long as your goal is to satisfy all or most of your employees, this is the way to follow.

On the other hand, if you are aiming to optimize your business processes through IT, this might not be the best course of action. Why? Ask House, MD – people lie or misguide you even without an intention to do so.

“Everybody lies…” – House, M.D.

When defining the requirements, future users tend to request lots of features that are rarely used in the end. This practice is often pointed out as the reason why most of the requirements are wasted and nearly 65% of the functions are never or very rarely used.

3. You wanted to plan everything by yourself

Skip the GAP/FIT analysis or let your software vendor do it.

GAP/FIT analysis is meant to show if a product is a good choice for your requirements. Unfortunately, I rarely see it giving any valuable outcome. If you want your GAP/FIT analysis to provide useful feedback, you should:

• Create high-quality requirements that contain business process and domain models
• Prepare business cases that test your processes and domain-specific requirements
• Request the vendor to present to you how their product will solve those business cases

It is a very good idea to engage a freelancer Business Analyst to do it for you – he will be much more objective.

4. You’ve never established measurable requirements

Our phones are faster than computers from 10 years ago. Our laptops are faster than some servers 5 years ago. It can lead to a false conclusion that efficiency is no longer a challenge when it comes to IT. Unfortunately, it’s not that simple.

Today’s software is much more sophisticated, works on bigger data with many more dependencies. More and more of the communication goes halfway around the world before it reaches your browser and that communication is almost always encrypted.

This and many other, far more technical aspects, are the reason why we still need to think seriously about performance. It is a completely different story when you’re creating an app for 1000 users than for 1 000 000. It’s significantly different when you’re updating your reports with hundreds of records a day than when you’re doing it with thousands of records per second.

How does that refer to your requirements? We often see RFIs and RFPs with statements like “the system will be stable”, “the system will work fast”, “the system will be user-friendly”. As well as this sounds, it also provides no valuable information on how to approach the development.

If you are truly concerned about your system’s quality, be sure to establish measurable requirements. Here are some handy examples:

• The system will respond in under 3 seconds, serving 100 users at a time.
• The system will allow to upload up to 100k of data records in one transaction.
• The user interface will be designed in such a way that every report will be available in no more than 4 clicks from your dashboard.
• The system will be available 99,9% of the year.

These are examples of quite precise, measurable requirements. They help the developers to choose an appropriate approach (saving your money from too much optimization or preventing very expensive modifications after going live).

5. You’ve frozen the schedule and budget and have been changing the scope all the time

In project management, there is a concept called “project management golden triangle”. It’s a set of three basic constraints – scope, budget, and schedule. These constraints are bound together in a way in which changing one aspect always implies changes in others if the quality level is to be maintained.

It doesn’t necessarily mean that we have to meticulously plan every project detail before we start. The smart synergy between agile project approach and best software engineering practices gives us the tools to adapt the project to changing requirements with minimum implications for the budget and schedule.

Why is that so important? Software development requires decisions that are often compromises that support one concept but make another one more difficult. That’s why your project is only as good as your requirements are. Changing them late in the project can lead to lots of workload for adapting early approaches to the new concepts.

Understanding these dependencies will help you cooperate with your developer more efficiently. Adjusting the schedule and/or budget according to scope changes will enable you to have more control and more predictability in your development process. It will also let you keep the quality high.

6. You haven’t prepared the test data and test cases

One of the aspects that have the highest impact on project success is defining the success criteria. Providing your developer with a complete set of test data and test scenarios is a great way to make project completion a pleasure.

In many projects, the requirements analysis ends before the implementation. It is an archaic development model called ”waterfall”. Many studies have proven that such an approach leads to failures. Requirements analysis should not only support the development throughout the implementation phase and analyze the changes’ impact but also provide ways to prove how well the requirements are being met.

Preparing test scenarios and data will not only help you with the development but can also prevent many problems with data migration. Remember: if your business is unique – so is your data.

7. You’ve considered only COTS (Commercial Of The Shelf) solutions

There are many myths in the IT sector, one of which is the COTS software supremacy. A lot of consultants and CEOs tend to think that the best course of action when it comes to new software is to follow the “sector standards”. They take a Gartner’s report, choose a vendor and select a partner with the longest reference list for him. After all – no one has ever been fired for getting an SAP.

When you analyze your cases deeply, you’ll find that you only utilize about 20% of the software you have bought and you often change your business processes to fit the software.

“Differentiate or die” – Jack Trout

Companies are working hard to create and keep a competitive advantage. In the long run, it’s mostly sustained by unique processes and workflow. Did you consider risks of sharing it with other companies through your software vendor? Even if his integrity is pure – have you considered consequences of fitting yourself into a software solution rather than supporting your business model with a carefully tailored solution?

Just to be clear – I’m not saying every COTS is bad and that custom software is the answer to every challenge. I’m simply pointing out that it is worth to consider a different approach. In modern architectures, there’s a place for COTS software as a supporting solution in areas outside your business model (like accounting, team collaboration or warehouse management system – unless you provide accountancy services or operate a logistic center).

8. You didn’t customize it

The most important advantages of COTS software are:

• The vendor’s support
• Standardization
• Easy upgrades

Keeping that in mind, let’s consider customizing the software. Anything that overreaches the standard configuration features is a threat to those advantages which made you choose the pre-made solution. When your supplier changes the business logic, data structures for bending his software to your needs – you will shortly realize that you can no longer rely on the vendor’s support – Since he doesn’t know your customization, you no longer can benefit from the standard formats and integrations and each upgrade requires a lot of additional work to keep it compatible with your changes.

Apart from that, customization itself is often very expensive. It’s very uncommon to have a professional business analysis done before choosing a supplier. Customization is mostly a way to cover incompetence during the GAP/FIT analysis and it bends the requirements and software capability only for the purpose of meeting the contract requirements. It’s often calculated as time & material and demands a lot of effort from your team. When you calculate your staff’s engagement and long-lasting changes with serious workload – it’s often cheaper to keep COTS as it is and create a custom software solution that fulfills your unique needs and integrate it.

9. You’ve considered only the implementation cost, never calculated the ROI

When it comes to software implementation cost, many managers simplify the problem to the license cost and consultancy fee. There’s much more to that. To have a valuable view, we also need to calculate:

• The meetings costs (assuming approx. hourly rate 30 EUR/hour) apart from the cost of consultants
  • if throughout the implementation you will host 10 meetings, each one lasting 4 hours with 5 of your staff members it will cost you 10*4*5*30 EUR = 6000 EUR
  • if you need 2 days of training for your 50 employees it will cost you 2*8*50*30 EUR = 24 000 EUR
• Lower work efficiency through the change period:
  • Assume that it takes approx. half an hour a day for each one of your staff members to learn new software and that it takes 3 months to adapt to new interfaces, it will cost you 0,5*50*21*6*30= 94 500 EUR

Another aspect is calculating the positive financial impact of your new system. Basically, there are two main streams of positive cash flow impacts:

• Cost reduction, for example by:
  • Customer support optimization which leads to support staff reduction
  • Improvement of user interfaces which results in less time required for performing a task
  • Better material handling through the optimized resource management
• Income generation, for example, by:
  • Generating new leads from sales analysis
  • Optimizing the sales representatives’ routes, allowing them to visit more customers
  • Creating new sales channels – for example, you can prepare an API that allows other systems (e.g. your customer’s) to automatically place orders

It lets us treat IT more like an investment than a required, though hardly appreciated expense.

10. You wanted to choose one software for all purposes

There are quite a lot of aspects in which IT supports business. We have different software that can support many different areas of business such as:

• CRM – Customer Relationship Management
• ERP – Enterprise Resource Planning
• ECM – Enterprise Content Management
• DMS – Document Management System
• Workflow
• BPM – Business Process Management
• Project Management Software
• Collaboration platforms
• And many, many others

Unfortunately, there is a strong myth that it’s best to keep all those areas within a single software, with a single database from a single vendor.

There are a lot of arguments to the contrary. Firstly – it is next to impossible to find such a complex solution that fits all of our specific needs in every aspect. Secondly – it aggregates all the risks in one vendor. Thirdly – these solutions are expensive to buy, expensive to maintain and usually technologically outdated.

Nowadays, it’s much smarter to consider specialized solutions for different business aspects integrated through APIs. Hardware improvements, cloud solutions, and internet connection enabled us to maintain heterogenic environments that work together.

We no longer have to worry about data integrity as modern systems exchange it just as people do, instead of trying to keep it in one place, in one form, for all purposes. We can have COTS accounting system installed inside our office network, SaaS sales support software, hosted e-commerce solution all integrated by a custom CRM solution with automated processes supporting quality assurance and lead generation.

Summary

Implementing a new software solution is a complex business case that needs to be well prepared. It all essentially comes down to business analysis, requirements engineering and evaluating it through the whole project’s lifecycle. Here is a handy checklist that can help:

• Clear the business case with measurable goals
• Measurable non-functional requirements
• Professional GAP/FIT analysis checked against a CIM model and set goals
• Competitive advantages secured and well-supported
• Agile project approach – yet strongly engineered solution
• Non-critical, supporting COTS/SaaS software with quality API for integrations
• No customization of COTS software
• Test cases with real data coverage
• Calculate as investment, expect certain ROI and remember about indirect costs and positive cash flow impact

I hope this will make your new software order easier and much more effective.