Reduce coordination efforts without adding more meetings, more tools, or a larger budget

In many companies, system customizations, rollouts, and recurring initiatives are not one-off events but ongoing operations. Two or three times a year, major changes are scheduled; a dozen departments must be synchronized over the course of several weeks, and in the end, everything is supposed to go live over a single weekend. The technical implementation is rarely the problem. The real problem arises beforehand — namely, in coordination.

This was particularly evident in one of our projects with a financial services provider. The IT department had taken it upon itself to organize recurring system adjustments for the non-commercial systems, without a formal project mandate and without a dedicated budget for process improvements. Coordination was managed via Excel spreadsheets, email, and chat. It worked, but barely. However, the effort involved in coordination was enormous, and it grew with each iteration instead of decreasing.

Excel, mail, and chat work until they stop working

At first glance, there’s nothing wrong with these tools. Excel maps out plans, email conveys information, and chat enables quick follow-ups. The problem isn’t with any single tool, but with the way they interact, which, in reality, isn’t really an interaction at all.

An Excel plan shows a snapshot in time. It doesn’t show whether the person listed is still in charge, whether a task has actually been completed, or whether someone is waiting for a delivery. Anyone who wants to know the current status has to ask—via email or chat. The answer might come immediately, might come the next day, or might go to a distribution list that is no longer up to date.

In an organization with multi-level technical and organizational dependencies, this leads to an effect that is difficult to quantify but easy to feel. The coordination effort does not increase proportionally to the number of people involved. It increases exponentially. Every additional interface creates not just one more point of coordination, but several, because information is scattered across different channels, responsibilities are interpreted rather than looked up, and decisions are made verbally but documented nowhere.

Identify structural obstacles before considering solutions

The project’s starting point was typical of established organizations. There was no central leadership, either in terms of discipline or content, for the initiatives. The internal change management team did not feel capable of providing technical support for a project of this complexity. At the same time, the requesting department refused to set up a formal project because the overhead seemed too high for something that was essentially “just” organizational.

This is a pattern found in many companies. Coordination is treated as a secondary task that someone takes care of somehow. As long as things are running smoothly, it goes unnoticed. But as soon as the people involved change, an iteration fails, or an error occurs that no one can trace, it becomes clear just how fragile the foundation is. This is exactly where the project began, not with the introduction of a new system, but with the question of what is needed to ensure that coordination continues to function even when the framework conditions change.

Visibility beats control

The solution wasn’t an additional oversight body or a new reporting system. Instead, they used a tool the client was already using. No new implementation, no in-house development, no additional budget. The rollout was iterative, starting with a small group of users and then gradually expanding, with feedback loops and adjustments between iterations.

The key difference wasn’t the technology. It was that what had previously existed only in people’s minds suddenly became visible: which steps had been completed, where things were stalling, and who needed to take action next. Not just after a status check, but at any time, for everyone involved.

Roles instead of people, so that a change doesn’t cause any disruptions

This fundamentally changed the dynamics. Stakeholders no longer had to ask for updates. Coordinators no longer had to contact each participant individually. And if someone was absent, it was immediately clear where the process stood, because the status was documented in the system and not in a handover log that no one would have written anyway.

In organizations where responsibilities change frequently, person-dependent coordination is a risk. Not because people are unreliable, but because implicit knowledge is lost with every personnel change. The colleague who knew that Department X can only start after Y has given approval is suddenly no longer there. The successor doesn’t know the procedure, asks for clarification, might get a different answer, and the process begins to fray at the edges.

In the project, this problem was addressed by consistently organizing control along roles. The departments involved entered the respective responsible persons into the tool themselves. Responsibility for staffing lay where it belongs—namely, in the line department. The process itself remained stable, independent of individual people. This also means that when an initiative is run for the third, fourth, or fifth time, it isn’t necessary to explain from scratch each time who does what. The structure is in place; only the names change.

Automation where it reduces effort

Another key factor was the automation of routine communication. Notifications were sent automatically, and communication templates ensured that every message contained all the relevant information. No more “Can you send me the exact delivery details again?” or “I thought you’d already forwarded that.”

That sounds trivial. But in a process involving a dozen departments and spanning two months, it’s precisely these kinds of inefficiencies that add up to days of wasted effort. Automation doesn’t replace human decision-making here; rather, it prevents information that’s already available from getting lost.

The difference between coordination and control

Coordination means bringing stakeholders together and assigning tasks. It works as long as assumptions remain stable, everyone is reachable, and no one leaves. As soon as one of these conditions changes, coordination breaks down.

Steering operates at a deeper level. It ensures that dependencies are documented, that bottlenecks become visible before they turn into problems, and that decisions remain traceable even when people or priorities change. While coordination, at best, organizes the status quo, steering ensures that adjustments can be made without having to restart the process from scratch every time.

Tangible relief, at no extra cost

The project reduced coordination efforts by 40 percent. Just as important was a second effect: cross-functional issues suddenly felt less burdensome. Not because they had become easier, but because the effort required to address them had decreased. And all of this was achieved without additional licensing costs, without an external consulting project to implement the tool, and without a change management program.

The real lever, then, was not more resources or additional tools, but better governance, clearer roles, and a process that remains adaptable when conditions change. This is exactly where flowciety comes in, by treating coordination as what it actually is: a management task that requires structure, not just good will. With clear roles, transparent workflows, and tools that are already in place, so that recurring initiatives still work even on the fifth iteration.

In our white paper on IT architecture, we demonstrate how transparent processes and role-based control measurably reduce the coordination effort in complex organizations.

Source of cover image: master1305