Can you make it talk to the system we already use?

Two companies asked me this month whether a new tool could push data into the system they already run the business on. In both cases I couldn't give them a straight answer, because in both cases the documentation for the other system wasn't publicly available. That single unknown moves a job from a fortnight to a quarter, and it's usually the last thing anyone brings up.

The ways in, in the order I hope for

When somebody says connect it to our system, they're describing one of four situations without knowing which.

• The system has a documented, supported way for other software to read and write to it. This is the good outcome and it's rarer in industrial software than you'd expect
• It doesn't, but it will take a spreadsheet in and give one back out. Unglamorous, completely reliable, and enough for most of what businesses actually want
• Neither, so the only route is a tool that logs in and behaves like a very fast member of staff. It works, it breaks whenever the supplier changes a screen, and I'll tell you that before you buy it
• The supplier will build the connection themselves, for a fee, on their timetable. Sometimes that's genuinely the right call, and it's worth asking them before asking me

So the first thing I do now, before any conversation about cost, is ask for the technical documentation for the other system. Not a meeting about it. The document itself.

Ask for the document, not the meeting

On one of those calls the client offered to get the developer who looks after their supplier's connection onto a video call with us. Kind offer, and I nearly took it. Then I worked out that arranging a call across three diaries would take a fortnight, and the same person could email the documentation that afternoon. We asked for the file instead and had it the same day.

That's a small thing but it comes up constantly. A meeting feels like progress because there's a date on it. Getting the document is progress, because somebody can then read it at midnight and come back with a real answer instead of an impression.

The bit that catches people out

A chief executive said something to me in August that I've repeated to three clients since. His view of the software his whole company runs on was that what it says it does, and where it says it puts your data, isn't the same as where it actually keeps it. He's been living with it for years and he's right. The screens are a description of the data, not a map of it.

Which means nobody can promise you an integration on the basis of a demo or a screenshot. The honest sequence is to get the documentation, have somebody technical read it, try one small thing end to end with real data, and only then agree what the whole job looks like. Every project I've seen go badly wrong on integration skipped the small thing.

Two questions worth sending your supplier this week

You don't need me for this part, and it's useful whether or not you ever build anything. Ask them whether they have technical documentation for connecting other software to your system, and whether they'll send it to you. Then ask what your support agreement says about a third party connecting to it, because occasionally the answer is that they'd rather you didn't, and that's much better to know now.

If both answers come back positive, your options just got wider and cheaper than you think. If they come back vague, that's not a dead end either. It usually means the spreadsheet route, which is how a good half of the work I've delivered actually moves data around, including systems that run a business day to day.

The reason I push on this so early is that it's the one unknown that can double a build after you've signed. I'd rather find it in the first week, when it's a question, than in the fifth, when it's a problem.