IT contract specification — typical gap (not only) of integration projects
A poorly written IT project assignment is a black hole into which time, money and energy disappear. I know from my own experience that this is one of the most difficult parts of the project for everyone involved. The good news? This does not always have to be the client's concern — the responsibility for the correct definition of the assignment should also lie with the implementation partner you choose.
We want to connect it somehow
For a lot of IT people, system integration is a bit of an abstract issue. Therefore, if one expects everything to be clear to everyone from the first moment, they cannot be more wrong.
Requirements such as “do we want to connect the systems somehow” or “will it pull the data on its own” are already such a constant in integrations. In the beginning they are absolutely fine, after all, with this idea it all begins.
The problem arises when, with such an assignment, one goes straight to the design of the solution or even to the development. Alas, it's not an exception. This often happens within procurement, where system integration is being developed as a complement to the implementation of another system. Not infrequently, integration is the black sheep of an entire project, as it significantly increases its duration, increases the price and frustrates the entire project team.
Why this is an important topic
Because system integration is not a toy. Mostly it is a fairly extensive analysis followed by complex development and testing. Solutions are expensive and each change in the assignment can increase the price several times.
Because understanding is the basis. On IT projects, you usually meet a group of people who have very different views on what information is important.
Because roles have their weight. Not every customer is an “IT” and not every developer has an overlap in the business process.
Because every system has its rules and we need to know them. ERP, CRM, e-shop — everyone speaks a different language. And it is integration that translates to.
Because exceptions make up the rule. 80% works easily, 20% of scenarios can ruin you financially if not addressed right from the start.
Responsibility: who actually bears it?
Here we get to the crux. Assignment is not just up to you, the customer. Yes, you know what you need in business — but how it translates into a meaningful IT assignment, it's not just your job. This is also the responsibility of the implementation partner. The latter should ensure that key information is understandable to all parties and ask the right questions so that important answers are heard.
The right partner:
he won't just ask you “what do you want?”
but will askmaybe “how does your process work? , “what systems do you have?”, “why do you want it?” and “what happens if...?”
and then help you formulate the assignment so that it is the right basis for the technical and implementation part of the project
Your role? The only thing is to have the courage and patience to do it.
What we have to ask
Business process and use-case - a story that will affect how we design the integration, who it serves, what data it works with and what significance the solution has for the client. I often ask clients to take me into their work for a while and show me how it all goes now, what obstacles they encounter, what they pay increased attention to, and where mistakes arise.
Who can give us maximum technical information about the system? Contact with a specialist is ideal, but we understand that it is not always possible. We often get by with a “paper expert” in the form of technical documentation.
Who, and to what extent, will take care of the integration when the project ends? Will we pass the finished solution to the internal integration team? Will the support remain with the supplier? These factors will affect, for example, how the integration behaves in the event of an error. But also, at what stage of the project we should start training the internal team so that the handover goes smoothly.
What exactly should integration do? And yes, here we really want to hear detail at the level of each box, every condition and circumstance, or perhaps where the data is to be scattered everywhere when the manager clicks the “approve” button. And we will be happy to discuss each box and button with you.
Why companies are afraid of it
Many firms feel that when a contractor starts to scrutinize power, it means delaying the project and raising the price. The truth is exactly the opposite:
The more we ask at the beginning, the less time and resources it costs later.
Even at first glance, a small change requirement, which fundamentally changes the nature of the solution and its architecture can cost many times more than the original contract.
The clearer and more detailed the assignment, the smoother the progress of the entire project and a good atmosphere is maintained in the implementation team.
Apel: don't be afraid to speak to experts in your own language
System integration is not and will not be a simple matter. The right implementation partner should make sure that just as it is important to unify the very different language of IT systems, so it is also crucial to unify the mutual understanding of the implementation team members, who often have very different perspectives on how they view the whole solution.
So the next time you stand on the edge of the precipice on behalf of an “IT project assignment,” ask yourself a question: Is there really someone standing next to you who can build a bridge?
