It is very tempting to look at the latest price proposal you sent to a customer and say “this is the price our customer pays for our software development services”. While this is technically correct, it is both misleading and dangerous for you to think like that.
Why is this wrong?
On the face of it, things are straightforward enough.
Customer sends a list of requirements.
You make a project proposal, with activities, timeline, estimations, team allocation – and you put a price on it.
You deliver a service – the customer pays the price. That’s it.
But it’s not that simple.
Let’s start with the actual vocabulary and words we use for this type of contract and transaction.
The customer pays an amount agreed with the supplier and listed on the invoice.
The customer pays for the value of the services delivered.
The customer pays a price.
Sometimes, the reality is that the customer pays the price for not having done their homework well enough, and the quality of the work delivered by the supplier is lower than expected.
Or the customer pays the price for not having thought-through the project specifications. This results in frequent changes, re-writing of modules already developed, cost overruns, not to mention frustration and stress for everyone involved.
What is “paying the price”?
We are now talking about paying the price, not in monetary terms, but in a much broader, generic sense of the words.
This is the gist of it: customers always pay more than the price agreed in the contract, because they have many other associated costs for that transaction.
All customers have travel and accommodation costs related to working with any supplier of Software Services.
These costs might be lower or higher depending on the distance between them.
Even if you are fortunate to be able to do all activities remotely (sales, contracting, delivery, demos, implementation, support), then you are faced with managing Zoom Fatigue in the customer’s team, not to mention any perceived loss of communication quality they might feel during the project.
And the list is much longer. A customer might have high opportunity costs, if the product they wanted to deliver in September is delayed until March the next year.
In this time, a competitor might win significant market share by launching a similar product faster, market share that will be very expensive to win back, if that’s even possible.
The manager in charge of the project in the customer team might have to spend a lot of time selling it internally, trying to convince other departments that it’s a necessary project.
Then, once it started, to keep it on the list of priorities and not have the budget cut before the implementation is complete.
This effort, which takes time, is a direct cost for the customer, but it’s not something most suppliers see (or want to see).
In many cases, implementing one particular IT project might have extra costs in other parts of the company, to be able to incorporate the new project in existing workflows and infrastructure.
This could be in the form of hardware, infrastructure, software licenses or extra people to be hired. It’s also important if they are one-time investments or ongoing operational costs.
Other big potential costs come from the risks the customer might have to manage.
Any new IT implementation project is risky by definition. It might or it might not be finished on time, on scope, on budget.
Too many times, it’s not. Which means that the customer has to plan for risk mitigation, to have alternatives in place or to take actions to reduce the negative impact it might suffer.
These cost time and resources, so they cost money. Another area where the suppliers usually don’t look at (or don’t want to look).
Why is this relevant for you as a supplier?
Because this has a direct impact on how much you are able to charge for any particular project or services you deliver.
When a customer is deciding who to work with, they are not looking only at the price offer they receive.
They are also considering all the other costs associated with that offer.
Different suppliers will not only offer different prices, but they will also have different risks, extra costs or timeline considerations associated with them.
So if you want to have a competitive offer and maximize your chances of winning the project, you have to take into account not only the services you provide and the price you charge for them, but the entire cost picture that the customer has to deal with.
Is there an opportunity in this?
Yes, there is a very big opportunity waiting for you on the other side of the fence.
Many customers are willing to pay if the supplier is capable of reducing risks or decreasing the customer’s costs in other areas.
For example, if you can offer a project as a fixed price, fixed scope contract, most rational customers will accept a slightly higher price than if the same scope of work were to be charged on a Time and Materials basis (whether hourly, daily or sprint-based rates).
What slightly higher means depends a lot on you and how you present the options to the customer, what credibility you have in their eyes and many other variables.
Also, crucially, notice that I wrote fixed price, fixed scope, but not fixed price, fixed scope and fixed timeline.
And this is just one example of the ways in which you can help your customers reduce overall costs or manage risks, while charging more for your services and making a higher margin.
If you have read about Michael Porter, you might have learned that there are three main reasons companies buy from services suppliers:
- To increase their revenues
- To lower their costs
- To decrease their risk
I found it very useful to always keep this in mind when making a project proposal for customers of Software Services.