The Most Important Part of an Implementation for Customers
Shortly out of school I interviewed for a project manager position. The interviewer asked me what the perfect project looked like, and I responded that there was no such thing (I didn’t get the job). No implementation is perfect, but if you, as the customer, could do one thing to make your entire journey that much better, what would it be? Continue reading to find out.
This topic is likely to spark debate as there will be varying opinions based on experiences and perception. Having managed implementations on both the customer & vendor side and done close to 30 go-lives, I’ve learned that customers can do one thing to dramatically improve their customer journey. Can you guess what it is? I’ll give you a hint - it occurs before signing on the dotted line.
Workflow and/or workstream mapping prior to engaging with any sales team is the most important thing you can do to improve your implementation journey. Why? Because you have to understand how you work to successfully choose a replacement product. In my experience only around 5% of customers do this, and you can help make this number grow.
Mapping your workflows is important because it allows you to have intelligent discussions with the vendor. It prevents the scenario of starting an implementation only to realize that the product or system is not ideal for you or won’t work at all. With workflows in-hand, you can work with the sales engineer to walk through how and why you work the way you do. This allows him or her to understand all the different things you do, and in turn, you will then clearly see if the product will improve on what you do, keep things the same, or force you to move backwards.
Thus far, I have worked for three vendors. At each one I’ve heard one of the following two comments from customers after the implementation started:
“I didn’t know that it worked like that”
“I’m not sure how this will work for us.”
Don’t let this be you…
It is not the sales team’s responsibility to decide if their product will fulfill 100% of your needs. It is your responsibility and let’s briefly discuss how to avoid this pitfall.
As mentioned earlier you need to map out your workflows and integration points. If you’re not sure what the best tools are for workflow mapping, you can reference my earlier post Tools of the Trade.
After your workflows are documented, create a requirements matrix. I like using the one below because it forces the sales team to be honest about what functionality actually exists today.
Now that your workflows are documented and you have a requirements matrix, send these to interested vendors.* Invite sales teams for an initial review whose product has the functionality you’re looking for. Explain to the sales engineer why you work the way you do, what your current pain points are, and what would be cool functionality to have in a solution. From here the sales team should do one of two things:
Build a tailored demo if you are procuring software with no physical components
Build a proof of concept for everything else (if the vendor doesn’t offer a proof of concept, ask for one!)
When the time comes to watch the demo or review the proof of concept, ask the sales team to provide lunch - it’s the least they can do. The demo or proof of concept will enable you to decide if what the vendor offers is worth buying. However, this works only if you have documented workflows and a filled out requirements matrix to guide your discussion. Going through these exercises will surface questions for you and help you to scrutinize what you’re seeing. If you purchase something after only seeing a demo or two, you’re screwed. (This still happens believe it or not. I once took over a failing project for a customer who made the purchase after doing nothing but watch two demos. I got the project through the go-live only to see customer resources sad to be using the new system).
After you find a solution that meets your needs and a vendor whom you feel will make a good partner, it’s time to move to the next procurement phase: contract negotiation.
* If you work for the government or a similar entity, you will be required to write an RFP. In a future post I’ll cover how to structure your RFP for success.