How to avoid a bad IT implementation

By - October 23, 2015

In technology when a large implementation fails at a large entity, such as an SAP implementation in Marin County, California a few years ago, it is all over the news. What about when it happens to companies in the mid-market. Even though it doesn’t make the news, is the effect any less on the business? The economy loses billions every year to failed IT implementations and I would argue that any down time in the middle market may be much more detrimental to that business than it is for a larger corporation. Chances are that in the middle market, there are several companies doing what you do and they would be more than happy to take care of your customers, while you sort out your “IT Issues”. A large corporation, especially ones who effectively own their market i.e., a cable provider, should be able to absorb the hit much easier.

So how do we avoid a bad IT implementation?

The number one thing to remember whether you are a client seeking help, or a consultant providing the help is this. You cannot rush the discovery phase of your project. Big or small, a for-profit company or a government agency, this is true for all of us.

Proper discovery benefits both the client and provider equally. If the discovery is done well, this enables a clear work plan to be laid out. Both client and provider are on the same page about what is getting done for their money, while allowing the provider to manage any “scope creep”. The goal is to never be surprised by things you should have discovered before you settled on your project plan. These issues of course will inevitably come up no matter what you do, but they should be mitigated as much as possible before you start. So how do we deal with them when they do come up? That question will bring us to our next point.

The project management team must have the right personnel. Make sure you have the right people, and they are communicating effectively. Your provider should have a dedicated project manager for your implementation and this person should not be the onsite engineer that you deal with day to day. As a client, at a minimum, one of your employees should be a main contributor on the project. Even if you only have 25 people one should still be appointed. In a larger small business with 300+ employees you should probably have several people from your different departments involved. Your provider should speak with them during the discovery phase. The provider’s project manager serves many purposes. They keep the team on track, they promote accountability for all involved, and they allow the client a direct avenue to management if there are concerns that need to be voiced. Your main point of contact makes sure all departments are making progress on their tasks, and keeps the provider accountable by making sure the CEO and other executive management are well informed. As with anything, making sure you have the right people in place is the key to success. This brings us to our third point.

Don’t make the new, old. It seems like at least once a year we run into a client that purchased a software solution, because they could not use the old system anymore for whatever reason and instead of adapting to the new system, they spent thousands of dollars having it customized to look, feel, or navigate like the old system. This is a common trap. If you can avoid this, try to do so. You will have to retrain your people, but your implementation cost is less and the system is much more supportable and less costly to operate. Also, you are a lot less likely to experience outages with the “out-of-box” functionality than you are with your customizations. There are products out there however, that are made to be customized, such as Microsoft SharePoint, but most ERP, inventory management, and accounting systems are much better off with fewer customizations. This brings us to our fourth point.

Train your people on the “new stuff”. Inevitably when users hear the system is changing it starts a chain reaction of anxiety over what is going to be different. Nothing helps to negate that more than some kind of formalized training for the people involved. Any time I do a migration from older versions of Exchange Server, or Active Directory, I always build in the time to train the client’s IT resources, to manage the system. Typically there is no user training for a project like that, still, the people whom it affects are trained. The same approach should be applied to your users. Whether you go with a third party trainer, training directly from the provider, or from the software supplier themselves, it needs to be part of your plan. Getting your users comfortable and competent with your implementation should not be overlooked.

“Know where you are, and where you want to be.” The industry term for this is “gap analysis”. What are the gaps between the “as-is” and the “to-be” systems? Identifying functional gaps between the current and planned systems will help to make sure that as the project goes on, those initial goals are not getting lost, or being mitigated by other issues. I sat down with one of my clients several years ago after they had done a mobile app customization with a “lone wolf” developer. The initial requirements were put out to her, and she proceeded to build out their mobile solution. After a year of development and rollouts, the end product didn’t do what they initially wanted it for. It did bring them some new functionality, however it did not address the issue that originally brought them to a mobile solution. So back to square one. Make sure you know exactly what you want out of your implementation, and make sure you are sticking to it, and so is your provider.

“Know who you are working with.” Get those references, and check them. Make sure your provider has done this sort of project before. Make sure the people that will be on-site from the provider have experience with these projects. One of the complaints in the Marin County example I used at the beginning, was that they were using the project as a “training ground for inexperienced workers.” Don’t let that happen to your implementation. Although consulting firms do need to train their people, you should not be footing that bill, and if you believe you are getting inexperienced talent, say something to your Project Manager.

These are just a few of the things that can be done to help ensure your IT Implementation doesn’t go south. Above all, you must practice diligence. Defined by Steven K. Scott as “a learnable skill that combines persistence, a smart-working effort, rightly planned and rightly performed in a timely, efficient, and effective manner to attain a result that is pure and of the highest quality of excellence.” Remember that, and you should be OK.

To find out more about this or other ways we can assist you with your business needs, contact us at 800.274.3978 or email us.

Receive Posts by Email

Subscribe and receive notifications of new posts by email.