Buying and selling enterprise software is a tedious task.
Because, Buyer generally do not know what is required from software. On the other hand, Salesperson have minimal understanding of buyer’s business and requirements.
As a result, projects start with chaos. Sometimes, random fights between Buyer’s Project Board and Software Vendor (Supplier).
Don’t believe me? Well, here is some evidence!
First, let’s have a quick look at high-level software procurement process!
Initially, Buyer’s Project Team hits market with high-level business requirements. These requirements are often vague, unstructured and aspirational. Salespersons dealing with Project Team are generally very positive people. They say ‘yes’ to most of questions.
After scrutiny of multiple vendors, Buyer signs deal with preferred Software Vendor. Both parties very excited and happy. However, this excitement does not last long. As first project kicks-off, Buyer’s Project Sponsor gets news from Vendor’s Software Consultant.
Consultant – “Business requirements are very complex and unique. We have to customise software to meet business needs”
Sponsor – “So what does it means?”
Consultant – “It means more development work, so additional cost and time. There can be some overhead during software upgrades as well…..”
Sponsor thinking – “What about my Business case???”
Senior management complains Vendor for not meeting expectations. There could be serious consequences for both parties.
But, why does it happens in first place?
There can be range of different reasons. However, I think one of the major reason is conflicting priorities.
Buyer’s Project Team is under pressure to select vendor and implement software in short period of time. On the other hand, Vendor’s Salesperson priority is to close deal as soon as possible. This is because Salesperson’s KPIs are sales number based. Therefore, Salesperson will do almost anything (within reason) to close the sale ASAP.
So, what we can do to avoid this?
In some of my previous posts, I have provided some guidance on software selection process.
You can refer to these posts under ‘RELATED’ section (at the end of this post).
Most importantly, both Buyer and Supplier should test if they are made for each other. In other words, before signing deal, both Buyer and Seller should undertake joint activity to test if software is ‘fit for purpose’. To do this assessment; Project Team should undertake solution architecture work with some prototyping.
If trial is successful then buyer can proceed for software procurement. However, if it does not work, it is fail-fast scenario. It is good for both parties. A win-win situation for both Buyer and Supplier!
What is your experience in software procurement? What are some of the lessons you have learnt? Share your story!