Disappointment is unmet expectations—the more significant the expectations, the more significant the disappointment.

When it comes to engaging with vendors to deliver significant business systems, the expectations are huge, and not every retail business is great at articulating these expectations. In the early stages of a software project, expectations are often referred to as requirements.

Communicating with Clarity

Clarity in communicating requirements is one of the most critical foundation elements of engaging with a vendor to deliver a project. Consider it your ‘working brief’ to the vendor. The more detail and context you can provide, the more likely it is that the vendor will be able to understand your needs and current pain points, and where you want to get to.

Gaps will still happen; communication can be tricky! Businesses develop their own shorthand or interpretations for particular words and create meaning around them. It’s not always easy or obvious to an outsider what is meant. Especially words like ‘pack’ and ‘print’ which have everyday uses, have evolved in a specific business and have layers of meaning added to their everyday use. *These words are both lived examples of business expectations not being well articulated to the vendor, resulting in multiple rounds of interpretation and review.

Vendors too may use terms that aren’t familiar to you, and they may use different terminology than you would use. Don’t assume that because they are using a particular term, they mean exactly the same thing as you do, or that when they’re making a commitment that they mean what you are expecting.

We’ve worked on lots of projects managing multiple vendors and here are a few that have cropped up multiple times that as a client you should consider carefully.

Vendor Promises

What are some promises to be wary of when you engage first with a vendor?

We know it works in business X, and we’ll do the same thing for you.

Creates the expectation, or the vendor assumption, that your business is the same as this other business and that things will work in the same way. This is rarely true; even in the same industry, each business can present differently. It’s very hard to pick up a process that serves one organization and parachute it into a different organization. It rarely works because it’s not connected to the same systems, processes and culture. The process, the nature of the business, the intentions are rarely and easy swap in and out.

Even if this promise feels like it should work, test the assumption. Ask, what is the same/ different about this situation and the vendor’s previous experience? What similarities does our business have to business X?

Timelines that are presented in blocks/ timelines that only describe the vendor activity.

Explainer decks, where vendors are presenting to a potential client, show present a timeline that explains what they are going to do and how long it should take. These pretty presentations rarely articulate what the client business team will need to do and what those people need to bring to the situation. It’s an example of the ‘perfect’ project where everyone is ready and knows exactly what they need to do (and has the time to do it).

A vendor cannot complete successful project implementation without some cooperation and input from the whole business from ownership through to people who will be using the software. If the business activities are not considered in the timeline, that is a warning sign.

To test the perfect timeline that is presented, ask which activities can be completed without your business input? If you cannot provide information or data/ business knowledge, what impact will this have on the timeline? Try asking what the vendor will need from you at each stage of the project.

A vendor suddenly drops a price after they learn what somebody else is offering.

When choosing a system most business owners look to the market to understand what’s on offer and what best fits their business. Vendors present and estimate to their best knowledge what’s feasible.

When one vendor’s price drops without any explanation as to why or how it usually means that you (the client) are compromising on something. What’s often not clear is what the compromise is. Selecting on price alone is never a good strategy but everyone has to work with constraints, budget being one.

Ask, what is the vendor not doing/ not including/ changing to make this new price work for them? Has a critical must-do function been dropped or the more desirable thing that you can cope without?

Even when we see business teams who make the most incredible detailed effort to brief a vendor properly, gaps can still happen. A vendor has not sufficiently appreciated how important something is to the business teams and (wrongly) expected to be able to replace it with something simpler that doesn’t do the whole job.

In my experience, I have found that the best way to close this gap is to ask questions. And keep asking questions until you’ve run out.
Knowing the right questions to ask can be tricky if you have not worked with vendors before.

That is where we can help. If you are looking for help creating professional documentation for your business, we can work with you to develop the necessary materials. By clearly communicating your needs to software vendors, you can ensure that your business requirements are met.