A great system, implemented badly, will probably fail. A mediocre system, implemented beautifully, will probably succeed.

In the IT world, there are often projects that require selecting a product. The team determines requirements, creates a long list, reduces it to a short list, and makes a selection. This is usually done with large systems, like ERP.

It is important that we get the selection process right. The wrong technology can hamper our organization for years.

However, implementation is at least as important, if not more important, than selection.

Portions of this article are excerpts from my book, The I.T. Leaders’ Handbook, available in paperback and ebook from fine bookstores everywhere.

Implementation is so important that it should be part of the final selection decision. Too often, we leave implementation planning until after the selection process and then we run into problems.

Consider our short list. 2-3 vendors that the team has determined that, yes, these products could work for us. I suggest that if we don’t know that these products will work for us, they shouldn’t be on the short list.

When we get to the short list, we will be tempted to have more demo shoot outs, maybe setup a sandbox with some of our data in it, and otherwise do a deep dive into picking the very best one. This is all fine and good, but there is an important step that is often overlooked.

How well can we implement each product? Rather than wait until we have selected a product, start the implementation planning at the short list stage. The information we uncover about the products, vendors, and our own organization will greatly improve our selection and implementation.

Here are some items that need to be in our implementation plans and will be helpful in selecting the correct product.

• Define Success: This isn’t the feature set. This is describing the world after we implement the system. We should do this before we start the selection process, but we can at least do it here.
• Stakeholders: The list of people affected by the new system is probably bigger than the representation on the selection team. That’s ok. But they must be on the implementation team.
• Training: This is an area that vendors love to brag about but usually sucks the most. Lay eyes on the training and see specifically how it will work for everyone.
• Data: Any major system will need data from existing systems and will pass data back and forth to other systems. Start laying this work out. How good are the tools that the vendors have? Are they good enough to use after we go live? Or are they secret magic stuff that only the vendor can use?
• Interfaces: All major systems have interface to other systems. All vendors claim that their system can interface with anything. Here is the hard part: vendors rarely implement interfaces the way we want them to be implemented. This is especially true with web services. Get the interface documentation and have a developer design a critical interface. We may not write code, but we can at least see where the architecture differences are. Much better to discover them now than after we have signed the contract.
• Security: Vendors always claim great security and are mostly correct. It is how that they implemented the security that can be problematic. If we do a high-level design of our security implementation, we will see if there are any major issues with a product.
• Go Live: We will need to determine the go live method: big bang, phased, or parallel. What works best for our organization and what the vendor supports may be two different things.

The last point I will make about starting the implementation planning as part of our selection process is that we will learn from the vendors. Each of them will say, “In our experience, we do these tasks for a successful implementation of our product.” If we hear this from several vendors, we can get good ideas from multiple sources.

I’ll repeat this again: A great system, implemented badly, will probably fail. A mediocre system, implemented beautifully, will probably succeed.

Photo by Thomas Kinto on Unsplash