Embrace politics to enhance IT/Business alignment

Why Traditional Process‑Focused Alignments Fail

Every January, the IT community wakes to a flurry of surveys asking executives what matters most to them in the coming year. New headlines emerge, but the same two or three items dominate the conversation - security, cloud migration, and data analytics. The rest of the list looks almost identical to last year’s. This pattern is a clear sign that the core of IT‑business alignment does not shift dramatically from one year to the next; it only looks new when framed in fresh language.

The most talked‑about item in these surveys is the alignment between technology and business. It’s the subject of endless podcasts, white papers, and workshops, yet improvement remains stubbornly elusive. The root cause is not a lack of goodwill. It’s the complexity of translating human relationships into rigid processes. When people try to force alignment through exhaustive interviews, documentation, and a cascade of approvals, they often lock a project behind a wall of paperwork.

Imagine a software rollout that requires a board of users to sign off on a single requirement document before any code is written. Each sign‑off triggers a meeting to re‑evaluate scope, which in turn invites yet another stakeholder to weigh in. The cycle can stretch a project for months, while the original goal - delivering business value - gets diluted or delayed. Users fear that their signatures could later be weaponised as proof of scope creep, so they resist signing. Executives, on the other hand, feel they are being handed a product that may not meet the promised ROI. The result is a wedge that separates, rather than unites, the two groups.

Process is not the enemy. It is a tool that, when misapplied, can become a barrier. A process that insists on unanimous agreement on every detail stifles the necessary trade‑offs that drive progress. It also turns negotiation into a game of “who gets the last word” instead of “who gets the best outcome.” When process dominates, relationships are measured by the number of approvals, not the quality of collaboration. Over time, this shift erodes trust and turns allies into adversaries.

Moreover, the focus on documentation and sign‑offs ignores the human side of alignment. Every stakeholder has motives, concerns, and expectations that evolve as a project moves forward. A static process cannot adapt to the dynamic nature of human decision‑making. The same set of rules that worked when the project began can become obsolete when a new business unit is added or a regulatory change surfaces. In those moments, the process becomes a rigid structure that forces stakeholders to fit into it rather than allowing the structure to adapt to their needs.

When alignment is broken, the symptoms surface in everyday project life: scope disputes, delayed budgets, and a growing sense that technology is a cost center rather than a strategic partner. These symptoms reflect a deeper failure - an inability to manage the politics that naturally arise when diverse groups pursue overlapping but distinct goals. Recognizing that politics is not a bad thing but an inherent part of decision‑making is the first step toward a more resilient alignment strategy.

Reimagining Alignment Through Constructive Politics

Politics, in the context of IT projects, means the mechanisms by which groups negotiate, influence, and reach decisions. It’s not about back‑stabbing or office intrigue; it’s about the everyday dance of priorities, constraints, and interests. When political dynamics are ignored or mishandled, projects stall. When they’re harnessed constructively, they become the engine that propels alignment forward.

Constructive politics differs from the self‑interested politics that often plague organizations. In self‑interested politics, each participant pursues personal or departmental gains without regard for the collective outcome. In constructive politics, decisions emerge from a shared framework of criteria - value, risk, feasibility - that all stakeholders acknowledge as legitimate. The challenge is to embed this framework into the project structure itself.

One of the most effective ways to achieve constructive politics is to design a governance model that reflects the external political landscape. Think of it as a miniature representative democracy. The project sponsor, business users, developers, and support staff each have a voice, and the decision‑making process respects majority rule while safeguarding minority concerns. When a developer proposes a new integration approach, the business side can challenge it on cost or timeline grounds, and the sponsor can mediate by weighing the trade‑offs. This transparency keeps everyone engaged and reduces the chance that a single group will dominate.

Process can still play a supportive role, but its purpose shifts. Instead of being the master regulator, the process becomes the framework that facilitates political negotiation. A lightweight set of rules - clear escalation paths, documented decision points, and agreed‑upon success metrics - provides a neutral ground. When everyone knows where to turn to resolve a disagreement, the political negotiation happens quickly and constructively, rather than through endless meetings or hidden agendas.

Another critical element of constructive politics is the early and continuous involvement of stakeholders. When representatives from each domain - sales, finance, operations, and IT - join the conversation from day one, the project builds momentum around shared goals. Their presence also ensures that concerns are surfaced before they snowball into larger conflicts. As the project progresses, this collective engagement keeps the political climate balanced and responsive to new information.

In practice, the transition to constructive politics looks like a series of deliberate choices. The project charter explicitly states that decisions will be made by consensus, not by top‑down mandates. The steering committee includes a mix of technical and business leaders who bring their expertise and biases to the table. Regular “pulse” meetings allow the group to surface friction points and recalibrate. By normalizing these political practices, the team builds a culture where negotiation is routine, and alignment becomes a natural byproduct.

Building an Advocacy System That Works

To operationalize constructive politics, many organizations adopt an advocacy system. The core idea is simple: each stakeholder group gets a dedicated advocate who translates its needs into the shared decision‑making process. Think of advocates as the project’s diplomatic corps. They ensure that the political voice of every group is heard without getting lost in the noise.

Start by mapping all parties affected by the project. For a typical enterprise software rollout, you’ll find sponsors from finance, end users from marketing, developers from the IT team, and support staff from the help desk. Assign an advocate to each group. In many cases, business analysts naturally take on the role of the business advocate because they already interface with executives and users. On the technical side, a release manager or a senior developer might serve as the technical advocate, ensuring that the solution remains feasible and maintainable.

Advocates are not gatekeepers; they are translators. They convert technical constraints into business language and business priorities into engineering terms. When a new requirement is proposed, the business advocate weighs it against strategic objectives, while the technical advocate assesses feasibility, resource load, and long‑term impact. Together, they present a balanced view to the steering committee.

The advocacy system also sets a clear balance of power. Instead of a one‑size‑fits‑all hierarchy, the project adopts a matrix structure that allows advocates to surface concerns directly to the decision‑makers. This structure prevents any single group from monopolizing the conversation and encourages mutual respect. When the steering committee sees that both business and technology voices are represented, it trusts the outcome more, leading to smoother adoption.

Day‑to‑day, advocacy manifests in recurring short meetings - often called “advocate syncs” - where each advocate shares updates, blockers, and upcoming decisions. These syncs serve as a pre‑screening process that filters out low‑impact discussions from the steering committee. The committee can then focus on high‑level trade‑offs, knowing that the advocates have already surfaced the critical details. This cadence keeps the political process nimble and grounded in real‑world data.

Beyond internal alignment, advocates can serve as ambassadors to external stakeholders. For example, a product owner may collaborate with an advocate to prepare a business case for an external vendor. The advocate ensures that vendor capabilities align with internal constraints, while the product owner highlights market benefits. This partnership reduces the risk of miscommunication and speeds up procurement decisions.

Ultimately, an advocacy system turns the abstract idea of constructive politics into a concrete, repeatable practice. It gives every stakeholder a seat at the table, ensures that the decision‑making process respects diverse perspectives, and embeds alignment into the fabric of the project’s daily rhythm. When stakeholders feel represented and heard, the project naturally gravitates toward the shared goal of delivering business value with a technology solution that satisfies all parties.

Sign up for free B2B and tech newsletters from Murdok at