How to justify integration costs to a client?

Question

We had developed a custom solution from scratch for our client. Recently the client asked for a quotation to integrate it with a third party software.

Unfortunately, we merely received a hastily guided demo of that software from its vendor, a demo API endpoint, and some paltry 'documentation' containing examples on how to call the API with no explanation of the data returned whatsoever. We've asked for more documentation or at least demo access to that software so we can 'reverse engineer' the API (kind of silly, I suppose) but unfortunately the vendor refuses to give any of that unless our client signs a year long contract with them.

Given the massive lack of visibility on this, I am hesitant to provide any kind of quotation. However, I was pressured into giving one, so I quoted a high price for it to cover the risks involved.

Of course, the client is unhappy with this and claims he can't afford to pay for it. Furthermore, somehow it seems that vendor has told the client that they can do the integration themselves at a much lower price by modifying our software.

While the code we've written now belongs to the client and they can do whatever they want with it, how do I tell them this is a very bad idea and will most likely fail? Also, the client is still paying us for software maintenance, so we would like to keep the code in a good state and of course, we would not want to be blamed (or be fixing) for any issues that might arise from the vendor's changes.

Answer 1

Presumably your client has shown your code to the third party and being in possesion of all the information they have less risk to cover than you when making their bid.

However, your client has the risk that they are simply putting in a low bid so that your client buys their main software and they might never deliver on the integration work.

Rather than try to explain your risk to the client. Highlight their risk with the third party option by saying:

1- Any changes to the code run the risk of breaking existing functionality

2- You are unable to continue supporting the product if changes are made to the code. Will the third party take over this support for the WHOLE product?

3- If the third party fails to deliver, or bugs are found after the work is comple and your client comes back to you to fix the problems. The costs are likely to be of a similar amount to you doing the work in the first place.

4- Suggest that the third party simply wants to sell their off the shelf product and has no interest or stake in the integration work. Where as you are committed to on going support and quality.

Answer 2

You consider the vendor a large risk, which in a fixed price situation means you have to cover it. Your quote is you honest assessment and you'd be foolish to lower it. I hope you've explained your reasoning to your client.

A time and materials contract would be better for both of you. You don't take on that risk (specifically you don't run the risk of being hung out to dry by your client's unreasonable vendor / your snubbed ex competitor). As the customer doesn't have to cover your risks, they get a fair price. The customer seems to trust the vendor more than you, and given his direct relationship with them is probably better placed to encourage their cooperation. I don’t think it would be hard to convince them that T&M is the cheaper route here.

While support contracts are a great source of recurring revenue, hopefully involving little actual work. Supporting your code after modification by a third party is not something I’d want to get into. While the T&M route should be presented as the probably cheaper heaven if they do, you sell this mess of (expensive for the customer, hopefully) software support as the hell if they don't.

Answer 3

A lot of my experience comes from the architecture/construction world and I think that there is a billing model you can borrow. Typically, the initial "schematic design" phase is billed by the architect on an hourly/time and materials basis and only after that is complete is the "construction documents" contract signed and the price set.

It might be worth it to try a two-phase approach: a initial development phase (call it "suitability study", "preliminary development", or something) at time and materials contract and a more normal contract to be determined at the end of the initial phase.

During the initial phase, you do need to have meetings and discussions with the client. You don't want to over-spend the client's willingness to pay.

Answer 4

Many customers can't stomach T&M so you are forced to do a fixed price quote - this is pretty common.

Can you do a fixed price quote for a Proof of Concept or a Minimum Viable Solution? Which 3rd party API, integrated with your solution, provides the most benefit with the least amount of risk?

Quote the MVS/PoC work with some contingency and set the expectation that the rest of the work can be quoted once the PoC is done.

At the completion of the Proof of Concept it should be pretty clear what your capabilities are, what the 3rd party team can handle, and the customer should have a good idea about who can actually deliver on time and on budget.

If all goes well and the 3rd party team is great, then your risk & price go down.

If it doesn't go well, then your customer should understand the source of the problem, and your price will make sense.

It is crucial that your customer knows that the complete solution will be an iterative process and you will be coming back to the well for more money. The customer should appreciate this approach because small projects succeed far more often than large projects: Gartner Survey