Who Decides IT? — IT Decision-Making and Governance in a Project

IT governancedigital solutionsdecision-making

A field note from a public sector digital project, with some reflections on why the process is designed this way.

This article is part of a series of reflections on technology, governance, and the spaces between them. The observations here are based on one project in one organisation. They are not a general theory, but a starting point for thinking about how IT governance actually works in practice.

Setting the Scene

The client is a public sector agency responsible for water-related policies — from water resource conservation and water supply management to reservoir management, drainage, and sewerage. Digital technology is not a peripheral tool for them; it sits at the centre of how they monitor, plan, and operate. That made the agency an interesting place to observe how IT decisions actually get made.

I was involved in multiple projects within this agency as part of a key partnership between the agency and my company. What I saw was not a single decision-maker issuing orders, but a distributed system of decision rights — what Weill and Ross would call an IT governance arrangement. This article is an attempt to describe what I observed, why it seems to work, and where the risks might be.

How IT Decisions Are Made

At the top-most tier, the agency's CIO office outlines a digital technology roadmap — a document that describes how the agency intends to use technology in its work. Crucially, this roadmap is meant to be aligned with the organisation's strategic goals. It breaks those goals down into several pillars of focus, each with major milestones such as key projects and initiatives.

The IT department is the main body responsible for delivering these initiatives. But it does not work alone. In each project, the IT department works closely with business units — departments responsible for drainage, water supply, sewerage, water quality, and so on.

Within each business department, there is also a small team of digital specialists. These are people who understand their department's day-to-day digital operations: data collection, maintaining their own databases (mostly data edits and new entries), and coordinating basic IT admin tasks like software licence applications.

So there are three layers of actors: the CIO office setting direction, the central IT department delivering, and business units providing domain expertise and operational validation.

Governance connection: This is a federated arrangement. The CIO office holds decision rights over IT principles and architecture (the roadmap). The IT department holds rights over infrastructure and project delivery. Business units hold rights over business application needs. Weill & Ross argue that this kind of federal model works best when decision rights are clearly defined and each party understands its lane. Here, the lanes are visible.

Project Level: How a Project Actually Moves

The project I was involved in was directly managed by the IT department. One solution specialist from IT oversaw project delivery; they liaised mostly with the project manager — that was my role.

Once a project is initialised within the agency — after a feasibility study and formal approval — it undergoes a procurement process (usually a tender) to identify a suitable contractor as the main body of implementation.

Within the project scope, I worked with business unit SMEs to:

gather requirements,
get their approval for the initial solution design,
after development, engage them for testing,
and eventually obtain their sign-off.

Once sign-off is complete, the project concludes, and a milestone on the technology roadmap is checked off.

Governance connection: This is where the governance model becomes operational. The IT department owns the delivery mechanism and the project lifecycle. The business SMEs own the definition of value — what the requirement actually means for their work. Neither side can unilaterally declare success. This separation of decision rights — delivery vs. validation — is a deliberate design choice. It prevents IT from building something technically sound but operationally useless, and it prevents business units from demanding features that are impractical to deliver.

Where Is the Line Between IT and Business Units?

The IT department manages the underlying digital infrastructure that supports all digital solutions — network configuration, VM or cloud resource allocation, and so on. It also coordinates the project pipeline: it has a say in which project gets prioritised, based on the IT roadmap. And it directly oversees software project lifecycles, from initiation to tender to conclusion.

Business unit SMEs, on the other hand, provide the business-side validation for a use case or requirement. They know their work best. They know whether a proposed feature actually solves a real problem, or whether it just sounds good in a requirements document.

Within specific projects, the IT department supports the SMEs by mobilising available resources to ensure that digital initiatives create business value.

Governance connection: Weill & Ross identify five key IT decision domains: IT principles, IT architecture, IT infrastructure, business application needs, and IT investment and prioritisation. In this agency, the IT department holds decision rights over infrastructure and investment prioritisation. Business units hold decision rights over business application needs. The CIO office holds rights over principles and architecture. This is a fairly balanced distribution — no single actor dominates all domains.

The Stakeholder Map

The diagram below shows the relationships between the key actors in this governance arrangement.

The key relationship to note is the bidirectional dependency between the IT department and business units. IT cannot deliver value without business validation. Business units cannot realise their digital needs without IT's infrastructure and project management. The CIO office sits above both, providing strategic coherence.

Why This Process Is Designed This Way

Several design choices stand out:

1. Separation of delivery and validation. The IT department builds and delivers. The business units validate and sign off. This prevents the common failure mode where IT builds something that meets the technical specification but does not solve the actual business problem.

2. A single point of accountability at project level. One solution specialist from IT oversees delivery. This person is accountable for the project's success. Weill & Ross emphasise that effective governance requires clear accountability — someone who owns the outcome, not just the activity.

3. Embedding digital specialists within business units. This is a smart move. It creates a bridge between central IT and the business. These specialists understand both worlds: they can translate business needs into technical requirements, and they can help their department adopt what IT delivers.

4. Roadmap-driven prioritisation. Projects are not chosen ad hoc. They emerge from a roadmap that is aligned with strategic goals. This gives the IT department a defensible basis for saying "no" or "not now" to requests that do not fit the roadmap.

Potential Benefits

Alignment with strategy: The roadmap ensures that IT investment is tied to organisational goals, not just departmental whims.
Balanced decision-making: No single actor dominates. IT cannot ignore business needs, and business units cannot bypass IT's infrastructure and project governance.
Clear accountability: At project level, the solution specialist owns delivery. At strategic level, the CIO office owns direction.
Knowledge transfer: BU digital specialists help embed digital capability within business units, reducing long-term dependency on central IT.

Potential Risks

Slow decision-making: With multiple actors involved, decisions can take longer. A federated model requires coordination, and coordination costs time.
Ambiguity at the boundaries: The line between IT and business unit responsibility can blur, especially when a requirement has both infrastructure and business implications.
Roadmap rigidity: If the roadmap is too rigid, it may not accommodate emergent needs or new technological possibilities.
Dependence on key individuals: The model relies on people who can bridge the gap — solution specialists, BU digital specialists. If these roles are not adequately staffed or trained, the model falters.

Governance connection: Weill & Ross warn against both centralised and decentralised extremes. Pure centralisation risks irrelevance to business needs. Pure decentralisation risks duplication and fragmentation. This agency's model sits in the middle — a federal arrangement. Its success depends on clear decision rights, effective coordination mechanisms, and capable people at the boundaries.

Concluding Thoughts

This was my first close-up look at how a large public sector organisation governs its IT decisions. What struck me was not the complexity of the technology, but the deliberate design of the decision-making process. The roles are defined. The boundaries are drawn. The accountability is placed.

It is not a perfect system. No governance model is. But it is a thoughtful one. And for someone like me — coming from a project delivery background and now thinking more about the policy and governance dimensions of technology — it was a valuable lesson in how the "who decides" question shapes everything that follows.