Why RAID control matters when technology projects start to drift

When enterprise technology delivery starts to drift, the warning signs are often already visible.

A dependency is known but not owned. A supplier milestone moves without a credible recovery path. A decision is discussed repeatedly but never made. An assumption remains open because nobody has tested it. A project stays green because the status pack describes activity, not evidence.

By the time failure is obvious, the project has often been losing control for weeks.

RAID commonly means risks, assumptions, issues and dependencies. Some organisations use variants, treating the “A” as actions or the “D” as decisions. In this article, RAID means risks, assumptions, issues and dependencies, with actions and decisions treated as connected controls.

Used properly, RAID control is not project administration. It is a practical way to make delivery risk, ownership, decisions and escalation visible early enough to act.

For complex enterprise technology change, that still matters.

Who this guide is for

This guide is for hiring managers, sponsors, recruiters and delivery leads who need to understand whether a technology project has real delivery control or only the appearance of it.

It is especially relevant where the project involves:

• finance, insurance or regulated enterprise IT change;
• supplier-heavy delivery;
• application, software or platform upgrades;
• combined software and infrastructure change;
• cloud, infrastructure or data-centre-related migration;
• service transition, readiness or cutover;
• unclear delivery status;
• reporting that feels optimistic but thin on evidence.

It is not a RAID template or a methodology guide. It is a practical explanation of why RAID control matters when delivery confidence starts to weaken.

RAID control matters most as complexity increases. A short, low-risk software change may need very light control. A multi-team, supplier-heavy, regulated or business-critical project needs stronger visibility of risks, assumptions, issues, dependencies, decisions and ownership.

RAID is not the same as a RAID log

The phrase “RAID log” can make the discipline sound administrative. That is one reason it gets undervalued.

A RAID log is only the record. RAID control is the behaviour around it.

The useful question is not:

Does the project have a RAID log?

The useful question is:

Is RAID control helping the right people see what could affect delivery, who owns it, what decision is needed and what happens next?

A project can have a long RAID log and still have weak control. If entries are stale, vague, unowned or disconnected from decision-making, the log becomes a filing exercise.

A smaller, sharper RAID view can be more useful than a large register nobody trusts.

The hard question is: why bother?

If a RAID view is not changing ownership, decisions, escalation or delivery behaviour, it is not control. It is a record.

What good RAID control should reveal

In real enterprise delivery, risks, assumptions, issues and dependencies are connected.

A risk may become an issue. An assumption may hide a dependency. A dependency may need a decision. A supplier milestone may create a readiness risk. A technical issue may become a commercial problem if it affects scope, cost, service or customer impact.

Good RAID control should reveal:

• what could affect delivery;
• what is already affecting delivery;
• what the project is assuming to be true;
• what depends on another team, supplier, system, environment or decision;
• who owns each item, or who is accountable for deciding what happens next;
• what action is being taken;
• what needs escalation;
• which items are most important now;
• what evidence supports the current status.

RAID should not sit separately from planning, reporting, supplier governance and sponsor decisions. It should connect them.

It also has to be current. A RAID view is time-bound: the top risks and issues last month may not be the top risks and issues now. As the project moves through design, build, test, release, cutover and service transition, priorities change. Good RAID control should make the current top items visible, not simply preserve a historical list of everything that has ever been raised.

The right risk has to be visible in the right place

Raising a risk is not the same as controlling it.

In enterprise delivery, there may be several risk views at once: a project RAID log, an IT delivery risk log, a service or BAU operational-risk view, a supplier risk register, a programme risk log and sometimes a wider portfolio or governance view.

That can be useful. If a project risk affects a live service, operational process, support model, customer outcome or regulatory obligation, there may already be an existing BAU or service operational risk that the project should reference rather than duplicate blindly.

The problem starts when a material risk is recorded somewhere that the right people never see.

If a risk is raised into a project log that nobody outside the project reviews, but the decision or ownership sits with a programme board, service owner, supplier manager or sponsor, the artefact has been updated but the risk is not yet controlled.

The project manager does not personally own every risk. The project manager usually owns the control process: making the risk visible, making sure it is assessed, finding the right owner, tracking actions and escalating where needed. The actual risk owner should be the person or function with the authority, knowledge or accountability to do something about it.

Getting that ownership agreed can be difficult. Few people volunteer to own a difficult risk, especially when mitigation needs budget, supplier pressure, senior decisions or uncomfortable trade-offs. If a risk has no credible owner, it is not really controlled.

Good RAID control therefore asks:

• is this the right level for the risk;
• who can actually own, mitigate, accept or decide on it;
• which forum needs to see it;
• whether it should remain a project risk, become a programme risk, cross-reference an existing BAU or service operational risk, or be reflected in supplier or operational governance;
• what decision or escalation route is needed.

It also means getting buy-in from people around the edges of the project, not only the core delivery team. Some of the people needed to control a risk may sit in service operations, architecture, security, finance, procurement, supplier management, business change or a dependent platform team. They may not attend the main project meeting, but their agreement, action or decision can still determine whether the risk is controlled.

Why RAID often becomes reporting theatre

RAID control fails when it becomes disconnected from delivery reality.

Common failure patterns include:

• risks written in vague language;
• issues left open without action or owner;
• assumptions never tested;
• dependencies recorded but not actively managed;
• ownership assigned in name only, without authority or acceptance;
• supplier commitments tracked separately from the main delivery view;
• RAID entries copied between packs without proper review;
• escalation avoided because the project wants to remain green;
• old items left open until nobody trusts the register;
• old priorities staying at the top after the delivery context has changed;
• pressure to create more risks simply to make the log look fuller.

At that point, the RAID log still exists, but it no longer gives control.

This is where reporting theatre begins. The project appears governed because the artefact exists. But the artefact is not helping sponsors make decisions or helping teams remove blockers.

RAG status and RAID control should work together

RAG status and RAID control are often treated separately. They should not be.

A red or amber status should usually be explainable through concrete risks, issues, dependencies, decisions or readiness gaps. A green status should be supported by evidence that those items are either controlled, accepted or not material.

If a project is green while the RAID view shows serious unowned dependencies, unresolved supplier gaps or unmade decisions, the status is probably not decision-grade.

RAG without RAID can become opinion. RAID without RAG can become detail without judgement.

The useful delivery view connects both:

• RAG tells sponsors where attention is needed;
• RAID explains why;
• actions and decisions show what happens next;
• evidence determines whether the status is credible.

That is the logic behind RAGnRAID: status alone is not enough, and logs alone are not enough. Delivery grip comes from connecting status, control and action.

RAID matters more when suppliers own critical delivery

Enterprise IT change often depends on suppliers, vendors, platform teams, internal service owners and specialist technical teams. Delivery risk is rarely contained inside one project team.

A supplier may have its own plan, reporting format and commercial milestones. The client may have a separate governance pack. Technical teams may manage work in Jira, Azure DevOps, ServiceNow or other tools. Finance may track purchase orders, forecasts, accruals and invoices separately.

If those views are not connected, delivery can drift even while each separate report looks acceptable.

Good RAID control helps connect:

• supplier commitments;
• statement-of-work milestones;
• delivery dependencies;
• technical blockers;
• readiness evidence;
• financial and commercial implications;
• decisions needed from the client.

This is not about turning the project manager into a legal contract specialist. It is about making sure commercial commitments and delivery reality are visible in the same control picture.

Assumptions and dependencies are where drift often starts

Assumptions can be more dangerous than obvious issues because they feel harmless.

A project may assume that an environment will be ready, a supplier will deliver on time, a business team will be available for testing, a security review will pass, a legacy system will behave as expected, or a decision will be made before a governance gate.

If those assumptions are not tested, they become hidden risks.

Dependencies create a similar problem. A milestone plan can look credible while the dependency path underneath it is already weakening.

Examples include:

• environments not ready for testing;
• supplier outputs needed before internal teams can proceed;
• security, architecture or change reviews not booked early enough;
• business testers unavailable at the right time;
• operational support not ready to accept the service;
• commercial decisions affecting scope or priority;
• data, access or integration dependencies discovered late.

A good dependency view protects the plan. It shows whether the date is supported by the work that needs to happen around it. RAID control should therefore be close enough to planning to challenge milestone credibility.

What good RAID control gives a sponsor

Sponsors do not need every detail. They need the right detail.

Good RAID control should help a sponsor understand:

• where delivery confidence is strong;
• where delivery confidence is weak;
• which items are the current priorities;
• which items need a decision;
• which dependencies threaten critical milestones;
• whether supplier commitments are being met;
• whether readiness evidence supports the proposed date;
• what escalation is needed and why.

That is different from sending a long list of entries.

The point is decision support. A sponsor should be able to see what matters now, why it matters, who owns it and what decision or action is required.

RAID control should be proportionate

Good RAID control does not mean creating a huge register or adding governance for its own sake.

More RAID entries do not automatically mean better control. In some projects, people are encouraged to “create more risks” as if volume is the objective. That usually has the opposite effect. Too many weak, duplicate or low-value entries dilute attention, bury the material risks and make the register harder to use.

This is where experience matters. Almost anything can be described as a risk if the definition is loose enough. Good RAID control depends on judgement: which risks are material, which are close enough to affect delivery, which need ownership, which need mitigation, and which are only background noise.

The right level of control depends on the delivery context.

Some people use the word “project” for a small two-week software delivery that behaves more like a sprint. That kind of work may not need a heavy RAID process. It may only need a light, active view of the few risks, blockers and decisions that matter.

A larger or more complex project is different. A regulated programme, supplier-heavy delivery, combined software and infrastructure upgrade, service transition or business-critical migration needs stronger structure, clearer escalation routes and better evidence discipline. The more teams, suppliers, systems, governance forums and operational impacts are involved, the more RAID control matters.

The aim is not a bigger RAID log. The aim is a trusted control view: specific enough to act on, short enough to use, and strong enough to show where ownership, decisions or escalation are needed.

Overcomplication creates resistance. Under-control creates surprise.

Warning signs that RAID control is weak

Warning signs include:

• the RAID log exists but is not discussed in decision forums;
• the same issues remain open for weeks with no movement;
• the register does not show which items are currently most important;
• risks are generic and cannot be acted on;
• low-value risks crowd out the few material risks that actually need attention;
• assumptions have no confirmation date;
• dependencies are listed but not owned;
• edge-of-project stakeholders are needed but not engaged;
• supplier risks sit outside the main delivery view;
• material risks are logged at project level but never reach the forum that can own or decide them;
• the project remains green despite unresolved blockers;
• decisions are discussed repeatedly but not recorded;
• reporting says “on track” but evidence is thin.

These signs do not always mean a project is failing. They do mean delivery control may be weaker than the reporting suggests.

The role of a contract Technical Project Manager

For a hiring manager bringing in a contract Technical Project Manager, RAID control is a practical test of delivery maturity.

A strong contractor should not simply ask for the RAID log and file it away. They should use it to understand the delivery position, challenge weak ownership, connect risk to milestones and help sponsors see what needs attention.

That means working with the client’s existing governance, tools and reporting standards, then tightening the parts that are not giving enough control.

In practice, that may involve:

• improving the quality of risk and issue statements;
• keeping RAID current as the project moves through design, build, test, cutover and service transition;
• connecting RAID to milestones, supplier commitments and readiness;
• making sure material risks sit at the right project, service, supplier or programme level;
• making ownership visible without pretending the project manager owns every risk;
• challenging ownership that exists on paper but not in practice;
• engaging edge-of-project stakeholders whose input or decisions are needed to control delivery risk;
• escalating decisions clearly;
• separating evidence from opinion;
• filtering material delivery risks from background noise.

The contractor should not need to impose a branded methodology. The value is in making the client’s own delivery controls work better.

Why RAID still matters

The work may be agile, waterfall, hybrid or something in between. The tools may change. The reporting format may change. The governance model may vary by client. But the core delivery questions remain:

• what could go wrong;
• what is already going wrong;
• what are we assuming;
• who or what do we depend on;
• who owns the next action;
• what decision is needed;
• what evidence supports the status.

If those questions are not controlled, delivery confidence is fragile.

For complex finance, insurance and regulated IT change, RAID is not an old-fashioned artefact. Used properly, it is one of the simplest ways to make delivery risk visible before it becomes delivery failure.

When this kind of delivery control is a strong fit

The strongest fit is a contract Technical / Senior IT Project Manager role where delivery status needs to become clearer, risks and dependencies need stronger ownership, supplier commitments need better visibility and sponsor reporting needs to support decisions rather than describe activity.

When delivery is drifting, the question is simple: who can make the risks, owners and decisions visible enough to act?

For role-fit, availability and engagement-route checks, use the RAGnRAID Contact page or Recruiters page.