Orchestrating IT and business teams in automation
Orchestrating IT and business teams on an automation project means building a shared language between the two and holding the alignment from kick-off to delivery. What stalls these projects is rarely the technology. It is the coordination between the people who know the process and the people who build the solution.
Why don't IT and business speak the same language?
The business team lives with the daily pain and wants a fast solution. IT thinks about architecture, security and long-term maintenance. Neither is wrong. The problem appears when each side assumes the other understands its priorities without anyone having explained them.
That mismatch has a documented price. PMI's study The Essential Role of Communications shows that two in five projects fail to meet their original objectives, and that half of those failures relate to ineffective communication. In money: for every $1 billion invested, $75 million is at risk from communication failures. The research is from 2013, and the pattern it measures looks the same in projects today.
When an automation project stalls, it is worth investigating the conversation before blaming the tool. Most of the time the bottleneck sits halfway between the two teams: requirements that changed without notice, and priorities each side understood differently.
How do you align expectations before the first automation?
Alignment work starts at kick-off and follows a sequence that saves rework.
- Map the current pains of the business in detail, listening to the people who run the process every day.
- Translate the needs into requirements both sides can read. If the document only makes sense to IT, it is not ready.
- Validate with everyone involved before any development, including limits, risks and deadlines.
- Write the decisions down to avoid reinterpretation three months later.
That last point is usually the most neglected. A recorded decision closes a discussion; a remembered one reopens it weekly. The same care applies to what already exists: documenting and versioning automations protects the project when the people who designed it change roles.
Which rituals keep both teams in rhythm?
Any team's routine is full of demands, and synchronization between departments does not happen on its own. A few simple mechanisms solve most of the problem.
- Short, frequent meetings between the main people involved, with a focused agenda and follow-up on open items.
- Visual boards and dashboards anyone can read without technical translation.
- A joint review at each delivery, with honest feedback from both sides.
- Room to experiment: small errors, corrected fast, teach more than months of defensive planning.
The format matters less than the consistency. A fortnightly meeting that always happens is worth more than a weekly ceremony that keeps getting cancelled.
What is leadership's role in the orchestration?
On automation projects, whoever leads carries two jobs: managing the schedule and translating between the departments when conflicts show up. Some competencies weigh more than others in that role.
- Communication without jargon restricted to one side.
- Systemic view, to see past the immediate problem.
- Authority to decide and unblock standoffs.
- Willingness to hear the business context before accepting any technical solution.
When leadership stays close, problems surface early and cost little. When it delegates everything and disappears, the problems surface at delivery.
Why does process design come before the tool?
Behind every automation that works there is a process designed with the people who run it daily. Promising systems fail often for a simple reason: they automate a flow that does not match how people actually work.
The data points the same way. In Deloitte's Automation with Intelligence research, immature and fragmented processes appear for the fourth consecutive survey as the top barrier to automating at scale, and 52% of organizations cite the difficulty of changing processes and ways of working when trying to automate end to end.
A hypothetical example helps. Picture a mid-sized distributor that decides to automate order approval. Sales asks for speed: approval in minutes. IT points out that the customer's credit limit is checked in a separate system, updated once a day. If nobody sits down together to redesign the flow, the automation is born approving orders on stale data, and the first bad debt becomes an argument against the whole project. A joint redesign, with an exception rule for orders above a threshold, would have resolved the impasse before the first line was written.
That is why we start any project by mapping how the work happens today, listening to the people who run the process, before discussing technology. If your operation does not have that picture yet, mapping the hidden bottlenecks is a good starting point.
How do you keep engagement after kick-off?
Losing momentum after the start is a recurring complaint on automation projects. The kick-off enthusiasm lasts a few weeks, the adjustments take longer, and the results slip. A few mechanisms hold the rhythm.
- Split the project into smaller deliveries and give visibility to each one completed.
- Show the impact of the changes for the end user, with numbers whenever possible.
- Train in short, practical sessions, learning by doing. Good user onboarding makes a difference here.
- Openly recognize whoever gathered requirements, tested and gave feedback, not only whoever built.
A small delivery celebrated creates traction for the next one. A project that only celebrates at go-live spends months without a visible win, and that vacuum is where engagement dies.
Which tools bring IT and business closer day to day?
The tool here is a supporting actor: its job is to reduce the friction of keeping everyone informed. Four categories usually pay off.
- Self-service portals, which let the business follow and trigger processes without opening a ticket.
- Visual workflow platforms, which show each stage of the flow traceably for anyone.
- Asynchronous communication channels, with dedicated space per project instead of scattered conversations.
- Trigger-based automations, which join rules defined by the business to monitoring by IT.
The selection criterion is context. A good tool is one the business team can use without depending on IT for every question.
Frequently asked questions
My company has no IT department. Does this orchestration apply?
Yes, and with more reason. When IT is an external vendor or partner, aligning expectations and holding review rituals is the only way to keep the project under control. The same mechanisms apply: requirements readable by both sides, decisions written down, and a review at each delivery.
Won't frequent meetings turn the project into bureaucracy?
The cost of a 20 minute meeting per week is small next to the cost of the misalignment PMI's research quantifies: ineffective communication sits behind half the projects that fail. The ruler is simple. If the meeting produces no decision and removes no blocker, shorten it or space it out. If rework appears, bring it closer.
Who should own the project: IT or business?
The business owns the result, because the process the automation serves belongs to them. IT owns the technical solution and its support. Naming a pair works well, one business owner and one technical counterpart, with autonomy to decide together what does not need to go up to the board.
Next step
If your automation projects stall more from misalignment than from technique, the first move is seeing the operation as a whole. An Operational Architecture Diagnostic is a 30 minute conversation to map where IT and business are missing each other and what to orchestrate first. Book a time.
Read next
Related case studies
Did you recognize your operation in this article?
Book the Operational Architecture Diagnostic: 30 minutes to map where your operation's bottleneck is. No strings attached.
Book a diagnostic