The Software Vendor & Client Disconnect Uncovered
Whilst there is an overlap in goals between business and vendor, both parties are playing a different game. A great outcome will be had by only one of the two parties.
No matter how lovely your software vendor or implementation partner is — their business model is not designed to (truly) help you. The less a software implementor (whether they are a vendor or an implementation partner) tailors their solution to your specific needs, the better it is for them. The more reuse a vendor can find; the more profit they will make on this implementation and the easier future jobs will be for them.
Software vendors are no longer able to charge a premium for their product or services; as such they now rely on volume. One cannot deliver mass and a bespoke service profitably in a commoditised market.
The Software Implementation Industry
I’ve recently consulted to a few different clients who have been implementing software into their business. Some of these clients worked with the software vendor as an implementation partner; others used a separate vendor to implement the solution. In both cases, there were more similarities than differences and, this leads me to the following realisation:
The disconnect in relation to client and vendor expectations lies not with individual vendors — the problem lies with the industry itself.
The practices that are considered acceptable within the industry are not that acceptable to clients, or even to other services providers such as me.
The Software Implementation Model
Whether one is a consultant or a software implementer scoping new projects from the outset can prove challenging. In the beginning, there are so many unknowns. What will the client be like to work with? How big will the project be? Will it require a complex solution?
Software implementers tend to approach scope by identifying a ‘like for like’ scenario. Build a website like this one here, or create the visual design for an intranet that is similar to this one using the corporate colours of the client. Functionality, effort and therefore cost relies on replicating the status quo with small improvements.
Clients spend tens of thousands of dollars on implementation and expect more than a ‘tidy up’ on the status quo.
Software Design & Delivery
Separating ‘design’ from ‘build’ can seem like the right solution. In this scenario, the two pieces of work are budgeted and carried out separately. Finalising the design (user and industry research, use cases, information architecture and wireframes or page blueprints) gives definite shape to the project and, allows vendors to quote with more certainty.
Unfortunately, approaching design and build individually comes with its own set of issues. The client will have to:
‘Guess’ at the cost of the overall project.
Assign a ‘reasonable budget’ to the upfront design.
Define a fair budget to the subsequent development of the site.
The client can be left short of funds for the overall project for the following reasons:
Underestimation of development costs.
The design solution is too expensive to build.
In reality, those involved in the design typically work closely with vendors to arrive at an overall solution. This approach ensures the design takes advantage of and works with the features of the product. For the remainder a delicate dance ensues until all three parties — client, and design and build partners, are happy with the approach.
Contingency and Scope
Vendors mitigate the risk of having to build or make more changes than planned by adding contingencies into their quotes — usually around twenty per cent of the overall build cost.
As contingencies erode, vendors push back on customer requests. Customers begin to feel like even the smallest, most reasonable requests are out of scope. Before too long the relationship has eroded.
Clients are left with a ‘bad taste’, and vendors experience little repeat business
The rule here is ‘to start as you mean to go on.’ The sooner the customer understands that their requests are out of the remit, the more likely they’ll be to play their part in managing scope. There are always choices when it comes to scope, including:
The customer finding the additional budget to cover the cost of the change
Deciding not to go ahead with the change
Going ahead with the change and use some of the contingency
In the latter case, it is essential to keep enough contingency to cover the duration of the project. This will need to include any necessary amends found during the user acceptance testing near the end of the project.
Of course, a great project manager will manage both the client and the scope effectively from the outset. The project manager will provide the implications and options for dealing with any out-of-scope requests. Additional items can be dealt with by swapping for another feature or by applying more budget.
Software development is expensive. At times vendors will need to undertake a complete rewrite of their software to keep pace with modern standards. Luckily for both customers and vendors, full-scale rewrites don’t need to happen very often.
With the fast rate of change in the tech industry, it’s easy to fall behind. The individual elements within any given piece of software are the first to slip below currently accepted standards. Workflows, social features, integration with other applications and services and, use across devices become dated and stop working in the way users expect.
People learn to put up with inadequate solutions and design.
Too often, vendors develop a ‘good enough’ product to meet generic use-cases and then shoe-horn clients into it. This industry’s top players hand this mindset down.
Twenty years on and users are still lamenting the usability of Microsoft Word. Even Microsoft’s newest offering M365 is problematic for the user with multiple accounts or participating in a Teams meeting with an average internet connection. Real-time collaboration on documents is a core use case for M365, but the experience is funky and weird, and users create workarounds.
Microsoft has been clear in their message that M365, Office etc. are not designed to take on corporate branding.
Other vendors dress their solutions up as bespoke — the reality is a core system that is almost always behind the times and an approach that provides a limited selection of interfaces with brand colours applied.
For most business people, the modest improvement that a new system brings is a vast improvement on the status quo. In this environment poor, generic, ‘cookie-cutter’ designs look good. One could argue that if the customer is happy, then it’s job done.
In my experience vendors do not have a curious mindset. With a focus on profit and commoditisation of implementation, vendors do not pursue excellence.
Software implementation is very much buyer beware.
Delivering excellent results to customers is not the mainstay of the software industry. Few vendors, if any offer a deep consulting service that digs into and meets the needs of the end-user, partner, customer and organisation.
In the current environment, the software is, or at least should be a small part of the implementation. As such, spend money and time on understanding the real end-users and the business opportunity.
Customers with a Limited Budget
DO — Source consulting services covering the overall design at the same time as you bring your implementation partner on-board.
DON’T — Source consulting services and development from the same vendor.
DO — Ensure your design and development partners work on the solution together to draw on the collective expertise of the group.
A good consultant will (amongst other things) help keep the vendor honest
DO — Source consulting services covering the overall design first.
DON’T — Source consulting services and development from the same vendor.
DO — Ensure there is overlap between the design and development aspects of the project.
DO — Have the design and development teams work on the solution together to draw on their collective expertise.
DO — Use your design consultants for quality assurance checking and advice throughout the life of the project.