How To Team Up: Building A True Alliance Between Functional And Technical Consultants

(Part 2 of 5 of the series “The Human Code of ERP”)

Let’s be honest. If you have spent any time in enterprise software implementation, you have likely noticed that there is often bad blood between Functional and Technical Consultants.

Between them lies a gulf of misunderstanding, passive-aggressive emails, and delayed project timelines.

The Simple Integration Incident

I have seen projects grind to a halt for weeks simply because two professionals were speaking completely different languages.

Picture a typical alignment meeting. The functional consultant, fresh from a workshop with the client, leans forward and says, The client needs to sync the manufacturing software with the ERP. It is very straightforward. We just need to build a simple integration with their current MES to send the data over.

The problem is that the functional consultant is selling the solution as “easy” mainly because they are not the ones who actually have to write the code. They provide very few details and take the technical execution lightly, completely underestimating the heavy technical implications involved.

To the consultant, an integration is just a conceptual bridge. To the developer, that same “simple integration” represents a nightmare of payload structures, timeout errors, security tokens, and missing data validations.

When the developer inevitably points out these complexities, unnecessary friction is born. The functional consultant thinks the developer is unnecessarily complicating a business requirement. The developer feels the functional consultant is trivializing their hard work and making impossible promises to the client.

The truth is that as functional consultant the job has difficulties that the developer cannot understand, and vice versa. The developer does not have to face the irrational demands of a panicking client, and the functional consultant does not have to navigate the unforgiving logic of system architecture. Neither profession is less important or simpler than the other. They just face unique struggles that the other side rarely sees.

The real enemy in this room is the ego and the lack of mutual understanding.

Welcome to the second part of The Human Code of ERP. Today, we are tearing down the silos between the people who design the business processes and the people who actually have to build them.

We are talking about how to forge a bulletproof alliance between functional and technical teams.

Two Worlds, Two Languages

To solve this conflict, we must first understand the root cause. Functional and technical consultants inhabit two entirely different realities.

The functional consultant lives in the messy, unpredictable world of human business. They walk the factory floor. They see the physical sweat of the operators. They deal with the anxiety of the CFO and the chaotic, illogical ways that humans actually perform their daily tasks. Their goal is to make the business flow smoothly.

The technical consultant lives in a world of absolute, binary logic. A database table does not care if the warehouse manager is having a stressful day. A system architecture demands rigid rules, precise definitions, and zero ambiguity. Their goal is to make the system stable, secure, and performant.

When these two worlds collide without a translator, disaster strikes. You end up with a system integration that is technically flawless but completely useless to the people on the shop floor because it does not account for the physical delays of a forklift moving pallets.

The Technical Consultant’s Myth

There is a common misconception that to bridge this gap, a functional consultant needs to learn how to write code. This is completely false. A great functional ERP consultant does not need to know how to program a script or write complex SQL queries.

However, they absolutely must know how a system thinks.

You do not need to know how to write the API payload. But you need to understand that when a system sends a message, it expects a specific response, and you must design a business process for what happens if that response never arrives. You must understand the difference between a master data table and a transactional table. You must grasp the basic laws of system architecture.

Your true job as a functional consultant is to be the ultimate human translator. You are the bridge, not a programmer. You must take the chaotic, emotional needs of the business and translate them into clean, logical frameworks that a developer can actually work with.

Protecting the Trenches

The worst type of functional consultant is the blind executor. This is the consultant who does not really care about the actual business need. They execute orders like a little soldier, listening to an illogical or completely unfeasible customization request from the client, writing it down exactly as spoken, and handing it directly to the technical team without questioning if it even makes sense.

Modern CloudSuite architecture prevents you from literally breaking the database, but users will still ask for modifications that completely violate the standard system logic. When the developer inevitably points out that the request is technically absurd, this type of consultant simply shrugs and says, “Do not blame me. That is what the client wants.”

This behavior destroys trust over time. It throws the technical team under the bus.

A true Consultant acts as a shield. It is your job to perceive if a request is totally unfeasible before tossing the ball to the IT department. You must apply the “Five Whys” we discussed in Part 1 and uncover the real business need.

Furthermore, if the developer struggles to execute a requirement, you do not just point at the specification document and demand results. You team up with them. You investigate together to understand if the technical limitation is objective. If it is an objective roadblock, you must act as a bridge and go back to the client to negotiate a middle ground.

Clients love to use the classic phrase, “In IT, everything is possible.” You must protect your technical team from this mindset because that is not how the real world works. We do not rewrite core processes from scratch. We extend standard functionalities.

When developers realize that you are standing at the gates, filtering out the garbage and protecting them from impossible promises, they will respect you. They will stop fighting your requests and start collaborating on your solutions.

Taking the Heat

Functional consultants often complain about a very specific dynamic. When a custom script fails or a system crashes, the technical consultant sits safely behind a monitor. Meanwhile, the functional consultant has to sit in a meeting room, look an angry client in the eye, and explain why the newly deployed customization is not working as expected. It feels incredibly unfair to take the blame for a technical error you did not write.

However, whether you like it or not, being the interface between the technical team and the client is exactly your job. You are the bridge. Complaining about facing the client is like a shield complaining about getting hit.

The secret to a healthy project is mutual defense. A strong alliance means you cover for each other. The functional consultant absorbs the shock, takes the heat, and manages the client’s frustration to buy valuable time. This dynamic only works if the developer has their back.

In a true partnership, the moment the consultant steps into that hostile meeting room, the developer is already informed and is working in the background to deliver a fix. You defend the developer from the client’s panic, and the developer defends your credibility by fixing the bug fast.

The Alliance Playbook

How do you turn a hostile IT department into your greatest ally? Here are three practical rules to apply in your next project to build a true partnership.

1. Write Binary Specifications, Not Novels

Developers hate ambiguity more than anything else in the world. Never write a functional specification that says, “The system should automatically update the status and notify the user.” That is a novel, not a specification. Instead, write in binary logic. Specify exactly which trigger fires the event. Define exactly which table field needs to change from Status A to Status B.

Clarify exactly what the notification should say and who the exact recipient is. Remove adjectives and replace them with precise conditions. If your specification leaves room for personal interpretation, it is a bad specification. Even the smallest details must be written down in a formal analysis and shared. A brief alignment call to review these details initially can make a huge difference in establishing a shared language.

2. Always Explain the “Why” in the Analysis

When writing your functional specification, you must clearly explain the business motivations behind the request. Do not treat the developer as a mere code executor. Just like functional consultants, developers need the full context of the requirement. They need to understand what they are working on, but most importantly, whythey are doing it. Do not just hand them a technical instruction.

Explain the business pain. Say, The workers in the warehouse are currently typing this number manually 500 times a day, and it is causing shipping delays. We need to automate this field to save them two hours a shift. When a developer understands the context and the human impact of their code, they transform from an order-taker into an active partner who might suggest a much better technical solution than you originally envisioned.

3. Make Them Part of the Journey

In most projects, the functional consultant is the one who travels to the client and sits in the important meetings. This dynamic often leaves the developer isolated in the back office. If you truly want to work as a team, you must do it properly. You cannot just ping your technical colleagues only when you have a specific coding task to assign without ever providing the broader context.

You must make them feel like an integral part of the overall project. Take the opportunity to talk to them regularly and align them on recent client developments, project shifts, and the overall atmosphere. Providing this continuous context ensures they are deeply involved. When developers understand the bigger picture and feel included in the journey, they stop being mere executors and become true project partners. A project where a functional consultant and a developer work in unison will undoubtedly yield excellent results for both the project and their daily work.

The Alliance in the Trenches

Building a custom extension or integrating an external software into an ERP is never just a matter of writing lines of code. It is an exercise in human communication.

The greatest technical architecture in the world will collapse if the people defining the process and the people writing the logic refuse to understand each other. By dropping our egos, learning to speak clearly, and protecting each other’s time, we can stop the eternal war and start building software that actually makes a difference.

A successful Go-Live heavily relies on the unbreakable alliance between a functional and a technical consultant. Neither can succeed working alone.

Next up: How to cultivate the most underrated skill in the consulting industry. We will explore the power of curiosity over encyclopedic memory.

Written by Andrea Guaccio 

May 7, 2026