RACI matrix for IT modernization in a government agency: roles and deadlines

Why “no one's” tasks appear in IT modernization projects

“No one's” tasks appear when the work is obvious to everyone but not assigned to anyone. As a result, each participant expects someone else to do it: the client thinks it’s the integrator’s duty, the integrator waits for data from the client, the SCS contractors do only what’s in the estimate, and InfoSec only steps in at the very end and sends the project back for rework.

In government organizations, approvals and acceptance often stall. The reason is simple: many mandatory participants and regulations, while deadlines are frequently tied to the budget cycle. If you don’t define in advance who prepares the document package, who approves it, who handles comments and who makes the final decision, approval turns into an ownerless chain of emails.

The items that most often become "no one's" are baseline data (room plans, list of workstations, InfoSec requirements), accesses and work windows (passes, escorts, shutdowns), interfaces and boundaries of work (SCS, network, server room, power), as well as test protocols, acts and as-built documentation. A separate risk area is fixing comments after a pilot and before final acceptance: everyone knows it must be done, but no one is assigned as the owner.

A common trap is a “list of responsible people” that still doesn’t answer the main question — who accepts and who is accountable for the result. That’s why you need RACI: it separates roles by participation type. Who performs the work, who is accountable for the outcome, who must be consulted (for example, InfoSec), and who is simply informed. Then every task has an owner and the project has a clear decision logic, even if the integrator (for example, GSE.kz) involves several subcontractors.

Project participants and where responsibility boundaries typically occur

IT modernization in a government agency usually involves 4–6 parties. Problems start where no one is assigned responsible for the “in-between” areas: who provides access to rooms, who approves routes, who confirms readiness for acceptance.

On the client side there are usually several roles. The IT team defines objectives, decides on architecture and accepts the result. Procurement handles contracts and delivery schedules. Facilities and operations are responsible for premises, power, building access and who will maintain the new equipment afterward.

The integrator holds the project together: the schedule, risks, contractor coordination, overall architecture, deliveries and commissioning. If the integrator also manufactures equipment and provides support, it’s important to clearly define where delivery ends and implementation, training and handover begin.

The SCS contractor typically handles the physical work: routes, trays, racks, outlets, labeling, measurements and final protocols. But their result often depends on others: access to rooms, approvals for fire-safety requirements, or restrictions on working hours.

InfoSec sets the rules: what is allowed on the network, which settings are mandatory, and which documents are needed for approvals and audit. If certification activities are required, it’s better to list them as separate tasks rather than hide them inside “commissioning”.

To avoid “no one’s” zones, clarify interfaces in advance:

• access to premises, pass control, work windows;
• who approves the SCS diagram and connection points;
• who issues accounts and accesses for configuration;
• who accepts measurement protocols and as-built documentation;
• who confirms readiness for acceptance testing.

A simple example: the SCS is installed, but the server room lacks power readiness, and InfoSec has not approved network connection. If these items have no owner in the RACI, the schedule will slip even with perfectly executed cabling.

What to put in RACI: tasks, decisions and deliverables

The matrix works when you enter verifiable deliverables — not generic “people” or “the process” — so you can check what must be done, who accepts it and what is handed over next.

Start with the artifacts the project must have on hand. These are not only the final acceptance documents but also intermediate results that, if missing, will stop the next stage: survey report, agreed requirements, design documentation set, procurement specifications, test reports, as-built documentation.

Then break the project into phases and list key tasks at each phase. Usually five phases are enough: survey, design, procurement, implementation, acceptance. Phrase tasks so they end with a measurable result: “Agreed list of rooms and SCS connection points” instead of “Work out SCS”.

Mark tasks that involve handoffs: SCS, access to rooms and server rooms, InfoSec approvals, work windows, cutovers and rollbacks. If interfaces aren’t in the matrix, deadlines will quietly slip without a clear owner.

In each row it’s useful to record:

• the deliverable (document, act, configured service, handed-over access);
• the decision owner (who approves and is accountable for the outcome);
• inputs and outputs (what must be available before start and what is passed on);
• dependencies (who you wait for and who you pass to);
• criticality (what should not be left “to everyone”).

Example: “Work window for the network core cutover.” The client approves the window and constraints, the integrator prepares the cutover and rollback plan, the SCS contractor confirms the readiness of lines, InfoSec approves temporary access rules and logging. If you don’t specify who closes the result by agreeing the work window, the implementation will easily end up in the last night before launch.

R, A, C, I in plain words

The matrix is not for a pretty table but so that for each task it’s clear: who does it, who accepts it, who must be consulted in advance and who should be kept informed.

R (Responsible) — the doer. The one who actually performs the work: writes requirements, pulls cable, configures the server, prepares the act, collects approval documents. There can be multiple Rs if the task is large.

A (Accountable) — the owner of the result. They accept the outcome and are accountable that the task is completed. The main rule: there must be one A for each task. Otherwise the decision gets stuck between two managers.

C (Consulted) — those who must be consulted before work starts. Their requirements influence how the work is done. A typical example is InfoSec: if it’s not involved before procurement or configuration, a later ban, rework and schedule slip will appear.

I (Informed) — those who are notified. They are not asked to decide but should be updated at milestones: department heads, finance, operations.

Quick checks to avoid confusion:

• R: “Who does it?”
• A: “Who accepts it and who will be asked later?”
• C: “Who must be consulted before starting to avoid rework?”
• I: “Who needs to know the status?”

Example: “Prepare and approve the server connection diagram for the new server room.” R — integrator (prepares the diagram), C — InfoSec and operations (provide requirements), A — the client’s project manager (approves), I — the department head (receives status at a checkpoint).

How to build RACI in a single working meeting

A 60–90 minute meeting is usually enough to turn the matrix from theory into a working tool. Invite those who actually make decisions and do the work: the client representative (process owner), the integrator, the SCS contractor, InfoSec and operations.

Start not with the letters but with the list of deliverables and what “done” means: “agreed plan of work windows,” “accesses issued for the server room,” “signed acts,” “as-built documentation handed to operations.”

A useful agenda:

1. Confirm project boundaries and the list of deliverables by phase.
2. Walk tasks top-down and assign R (who does) and A (who approves).
3. Add C (who to consult) and I (who to inform).
4. Mark tasks that require formal documents or signatures.
5. Agree who maintains the matrix and how changes are recorded.

Discuss interfaces separately — where tail items most often appear: who initiates pass and escort requests, who approves temporary segment shutdowns, who prepares port diagrams after SCS work, who collects the acceptance package.

Fix two roles explicitly: who approves changes and who signs acts. Without this, any minor correction (add a point, move a rack, change a work window) becomes a dispute and consumes time waiting for decisions.

Finish by setting an update rhythm: for example, the integrator maintains the matrix and updates it weekly and after each plan change, while the client confirms changes on short status calls.

Template for role distribution across IT modernization phases

Below is a simple template to cover typical “no one’s” areas in projects that include the client, integrator, SCS contractors and InfoSec. Use it as a base and adapt to your environment.

Roles (how to name them in the matrix)

Usually five columns are enough: Client (result owner), IT operations (future users and on-call staff), Integrator (general contractor), SCS Contractor, InfoSec.

Minimal template by phase to avoid missing tasks

For the template to work, leave exactly one A in each row. If two As appear (for example InfoSec and the client on approvals), split the task into two: “prepare the package for approval” and “approve/issue an opinion.”

Reality check: during installation explicitly record who is responsible for work windows and for granting site access. If not assigned, commissioning almost always slips.

Example task set for the matrix: SCS, InfoSec, network, servers, acceptance

To make the matrix help manage deadlines, include verifiable deliverables, not large vague phases. Below are tasks where gray zones most often appear between the client, integrator, SCS contractor and InfoSec.

Technical handoff points usually get fuzzy at: approving SCS routes and penetrations (including fire-safety passes), port labeling and handing over measurement protocols; addressing and routing plans; creating accounts and roles on servers; access to systems for integration and testing; decommissioning old equipment (shutdown permissions, work windows, data migration and disposal paperwork).

For InfoSec, record concrete artifacts: whether a threat model is needed, which settings are mandatory (passwords, logs, network restrictions), who approves changes and how checks happen before commissioning.

For acceptance, put concrete items in the matrix, not just “run tests”:

• test scenarios and accept/reject criteria;
• commission composition and who is responsible for the protocol;
• who provides test benches, accesses and test data;
• who closes comments and in what timeframe;
• who signs the final act.

If there is a system integrator on the project, add a line to assign responsibility for maintaining a single change log and a single collection point for questions. This reduces the risk that SCS, network, servers and InfoSec drift into different chats and schedules.

How to embed RACI in project documents and daily work

The matrix stops being a “meeting table” when its formulations are carried into documents and routine. Then each task has an owner and each decision has one approver.

Move RACI into requirements, the schedule and acceptance

A practical approach is to attach RACI to roles rather than individuals and link roles to verifiable deliverables. In the requirements and schedule, next to each task indicate: who prepares the result (R), who approves (A), who must be consulted (C) and who is informed (I).

Typically record this in four places:

• Requirements: for each deliverable (diagrams, acts, reports, configurations) indicate A and acceptance criteria.
• Schedule: add a field “A (approver)” to each task and an escalation rule if the deadline is at risk.
• Contracts and annexes: tie A responsibility to milestones and acceptance conditions.
• Acceptance protocols: predefine roles and who may sign the final acceptance.

The rule remains: one A only. If two people approve, the decision stalls.

Change management and daily communications

To prevent changes from blurring deadlines, agree a simple flow: the change initiator files a request (R), the integrator assesses impact on schedule and budget (R/C), the client approves or rejects (A), InfoSec agrees only on items that affect risks (C), others are notified (I).

Status rhythm helps:

• weekly: overall status by phase, risks and decisions for As;
• 2–3 times a week: working status for critical works (SCS, network, servers);
• on the day of a blocker: message “what is stopped, who is A, by when a decision is needed”;
• after a decision: record it in minutes and update the schedule.

If InfoSec requests rework and schedules are tight, do not stop all work. Split the flow: security-impacting tasks go through InfoSec approval, while safe preparatory works (delivery, installation without commissioning, documentation) continue in parallel. A compromise is recorded as a temporary measure and its closing date is set by the A.

Common mistakes: why tasks are lost and deadlines slip

Schedule slips usually happen not because of “bad performers” but because of gaps in accountability. While the project runs smoothly they are invisible. They show up at approvals, tests and acceptance.

A typical mistake is multiple As on one task or no A at all. If “the client and the integrator are responsible for acceptance,” when a conflict arises it turns out no one is actually responsible. Each result must have one A with the authority to say “accepted” or “not accepted.”

The second pain is bringing InfoSec in too late. At the end requirements for segmentation, logging, access, certificates, domain settings or security tools surface and block acceptance. InfoSec should be C at the design stage and kept informed of changes so it doesn’t discover issues on handover day.

The third error concerns SCS: “the cable is laid, so it’s ready.” Without measurement reports, labeling, diagrams and as-built documentation you can’t hand over the object, and operations won’t be able to maintain the network.

A separate risk is when the integrator “is responsible for everything” but lacks authority for accesses, work windows and approvals. This happens in multi-contractor projects even with a strong integrator. Responsibility without authority almost always leads to delays.

Signals that tasks are getting lost:

• acceptance criteria are vague like “it should work”;
• testing is not planned or signed off by anyone;
• work windows are agreed at the last moment;
• documents will be “delivered later";
• decisions are taken in correspondence without an owner.

Pre-start check: is there an A for the test plan and acceptance criteria, for accesses and work windows, for the as-built documentation package, and for the final “permission to commission” from InfoSec?

Short checklist: how to know RACI is ready to start

Before starting work, quickly check that the matrix leaves no gray zones.

• For each deliverable (document, act, configured system) there is exactly one A and a named R.
• All interfaces between SCS, network, InfoSec and operations are separate lines (for example: “port labeling and diagrams,” “M&E rule requests,” “handover of server room access,” “work windows and rollback”).
• For acceptance there is a minimal required package of documents and, next to each document, who prepares, who approves and who signs.
• Approvals have deadlines and a clear escalation: what to do if a C doesn’t respond in time.
• There is a rule for updating RACI when changes occur: new subcontractor, replacement of owners, scope increase, or new InfoSec requirements.

Quick test: take 2–3 risky points (for example, introducing new servers, access to SCS in an occupied building, InfoSec approvals) and ask participants what exactly they must deliver and by what date. If answers match the matrix and do not include “well, that’s not ours,” you can start.

If the integrator runs the project, assign the matrix owner immediately: who collects edits and distributes the current version after each plan change. In large projects where the integrator covers delivery, implementation and support, this helps a lot. For example, GSE.kz as a manufacturer and system integrator often takes coordination of subcontractors and lifecycle support, so it makes sense to assign RACI ownership to their project management.

A realistic example: how RACI helps complete acceptance without leftover tasks

A district office modernizes workstations and the server room: PCs are replaced, the network is updated, new servers installed, racks and labeling are tidied. Mid-project it becomes clear some tasks are “between chairs”: the integrator waits for server room access, InfoSec waits for diagrams, the SCS contractor waits for a work window, and the client assumes it was already agreed.

At a working meeting the team fills the RACI not by roles in general but by the specific acceptance deliverables. For “migrate services to new servers” the R is the integrator, the A is the client project manager, the Cs are InfoSec and admins, and the Is are finance and users.

For SCS the logic is different: the SCS contractor is R for installation and testing, the integrator is C for port and patch-panel requirements, the client is A for providing premises and approving points, and InfoSec is C for physical access and logs.

Typically five forgotten tasks surface and you should explicitly include them in the matrix:

• accesses and escorts for the server room (who arranges, who meets, who holds keys);
• work windows and user notifications (who agrees the time, who sends notices, who accounts for downtime);
• as-built documentation (diagrams, labeling, port passports, equipment registers);
• tests and acceptance criteria (what we measure, how we prove it, who signs the protocol);
• training and handover to support (who trains, who accepts, where issues are recorded).

Agreements are recorded in minutes: for each task — one A, deadlines, inputs and outputs, and a separate line “what blocks the start.” After the meeting update the work plan: add windows, InfoSec approval stages and a checkpoint “ready for acceptance” with an owner.

Next step — a short 60–90 minute workshop where owners of acceptance by area (SCS, servers, workstations, InfoSec) are assigned and the required documents for signatures are confirmed. When choosing an integrator, it’s worth checking in advance who can close the full cycle: from equipment delivery to implementation and support, with clear responsibility boundaries and single change control.