We want to connect it somehow
System integration is a rather abstract matter even for many people in IT. So if anyone expects everything to be clear to everyone from the very first moment, they couldn't be more wrong.
Requests like “we want to connect these systems somehow” or “it will pull the data by itself” are staples in integrations. At the start they're perfectly fine – after all, that's where it all begins.
The problem arises when a brief like that goes straight into solution design or even development. Unfortunately, it's not an exception. It often happens in projects where system integration is developed as an add-on to implementing another system. The integration then frequently becomes the black sheep of the whole project, because it significantly extends its duration, raises the price and frustrates the entire project team.
Why this matters
- Because system integration is no toy.It usually involves fairly extensive analysis followed by complex development and testing. Solutions tend to be costly, and every change in the brief can multiply the price.
- Because understanding is the foundation. IT projects usually bring together people with very different views on which information matters.
- Because roles carry weight.Not every customer is a “tech person” and not every developer understands the business process.
- Because every system has its own rules, and we have to know them. ERP, CRM, e-shop – each speaks a different language. And integration is what translates between them.
- Because exceptions make the rule. 80% works easily; 20% of scenarios can ruin you financially if they're not addressed right at the start.
Responsibility: who actually carries it?
Here we get to the core. The brief isn't just on you, the customer.
Yes, you know what you need from a business perspective – but how to translate it into a meaningful IT brief isn't only your job. It's also the responsibility of the implementation partner. They should make sure key information is understandable to all parties and ask the right questions so that the important answers get said.
The right partner:
- won't just ask you “what do you want?”
- but will ask, for example, “how does your process work?”, “what systems do you have?”, “why do you want it?” and “what happens if…?”
- and then help you phrase the brief so it becomes a proper basis for the technical and delivery part of the project
Your role? Just one: have the courage and patience to let them guide you through it.
What we have to ask
- The business process and use case – the story that shapes how we design the integration, whom it serves, what data it works with and what the solution means for the client. I often ask clients to take me into their work for a while and show me how it all runs now, what obstacles they hit, what they pay extra attention to and where errors occur.
- Who can give us the most technical information about the system? Contact with a specialist is ideal, but we understand it isn't always possible. We can often make do with a “paper expert” in the form of technical documentation.
- Who will look after the integration, and to what extent, once the project ends? Will we hand the finished solution over to an internal integration team? Will support stay with the vendor? These facts affect, for example, how the integration behaves when an error occurs – but also at which phase of the project we should start training the internal team so the handover goes smoothly.
- What exactly should the integration do? And yes, here we really want to hear detail down to every field, every condition and circumstance, or where all the data should scatter when a manager clicks the “approve” button. And we're happy to go through every field and button with you.
Why companies are afraid of it
Many companies feel that when a vendor starts digging too deep, it means project delays and a higher price. The truth is exactly the opposite:
- The more we ask at the start, the less time and money it costs later.
- Even a seemingly small change request that fundamentally alters the nature of the solution and its architecture can cost many times more than the original project.
- The clearer and more detailed the brief, the smoother the whole project runs and the better the atmosphere stays in the delivery team.
A plea: don't be afraid to talk to experts in your own language
System integration is not, and never will be, a simple matter. The right implementation partner should make sure that, just as it's important to unify the very different languages of IT systems, it's also key to unify the mutual understanding of the implementation team members, who often see the whole solution from very different perspectives.
So next time you stand at the edge of the chasm called “IT project brief”, ask yourself:Is there really someone standing next to you who can build a bridge?
