Technology Project Risks: Examples and Controls

What is a technology project risk?

A technology project risk is an uncertain technical condition that would damage cost, schedule, quality, or safety if it materialised. It differs from a general project risk because you can usually test it: the uncertainty is about how a system behaves, and behaviour can be measured.

Three tests separate a real technology risk from a worry:

1. A mechanism. Something specific would fail — an API contract, a query plan, a data type, a permission model.
2. A threshold. You can state what “failing” means numerically: latency above 800 ms at 2,000 concurrent users, error rate above 0.5%, migration rejects above 2%.
3. An owner and a date. Someone is responsible for producing evidence by a specific point in the plan.

Risks that pass all three belong on the register with a test attached. Risks that fail the second test need a discovery task before they can be assessed at all.

Why do technology risks surface so late?

They surface late because the project plan rewards visible progress, and testing an assumption produces no visible progress. A team that spends two weeks proving an integration is unworkable looks slower than a team that spends two weeks building against an unverified assumption — until month five.

The scale is documented. BCG’s 2024 analysis of large-scale technology programmes found more than two-thirds are not expected to be delivered on time, within budget, and within scope, and estimated the waste at more than €20 billion a year across the companies studied.

Technical debt compounds it. The 2022 CISQ report *The Cost of Poor Software Quality in the US* put the annual cost of poor software quality at $2.41 trillion, with accumulated technical debt around $1.52 trillion, and cited survey data showing developers spend about 33% of their time — 13.5 hours out of 41.1 — on debt rather than building. Debt is not itself a technology risk; it is the interest rate on every deferred decision.

What are the technology risks that actually derail projects?

Six families cover most of what goes wrong. Each has a distinct early warning signal, and each needs a different control.

Unproven technology

The risk is not “new technology”. It is a specific capability nobody on the team has demonstrated. The control is a spike: a timeboxed experiment — typically three to ten days — that answers one question and ends with a written verdict of workable, workable with constraints, or not workable. Write the question first: “can the event stream deliver 5,000 messages per second with under 200 ms end-to-end latency on our infrastructure?” Then build only what is needed to answer it.

Integration

Integration is where technology projects discover that two systems agree on the word “customer” and nothing else. Different identifier formats, time zones, ideas about a valid state, and retry semantics — all invisible until the first real payload crosses the boundary.

The historical record is brutal. Levi Strauss migrated to a single SAP system on a budget under $5 million; interface demands from a major customer, insufficient controls, and an inability to fill orders during cutover contributed to a $192.5 million charge against earnings in 2008 and the departure of its CIO. Hewlett-Packard’s SAP migration produced a $120 million order backlog and $40 million in lost revenue in 2004 after data-modelling issues blocked orders between the legacy system and SAP — against a project estimated at $30 million. FoxMeyer Drug’s $65 million ERP programme ended in a 1996 bankruptcy filing.

The common thread is not bad software. It is interface assumptions that were never tested against the real counterpart system until go-live.

Performance and scale

Performance requirements are usually stated as adjectives: fast, responsive, scalable. They need to be numbers attached to a scenario. “Search returns results in under 400 ms at the 95th percentile with 50,000 concurrent sessions and a 20-million-document index” is testable. “The search must be fast” is not.

The trap is testing performance at the end, when the environment is finally stable. By then the architectural decisions that determine performance are six months old, and fixing them means rework rather than tuning.

Security and privacy

Security risk is peculiar because the control is cheap early and nearly impossible late. A threat model in design takes two days and changes the architecture; the same finding in penetration testing takes two weeks and changes the schedule.

The concrete controls are well understood: model the threats against data flows, define who can read and write each entity, test authorisation as seriously as authentication, and keep secrets out of code and logs. What fails in practice is sequencing — reviews scheduled as a final gate, when the design has already hardened into code.

Data quality and migration

Migration risk is usually a data risk wearing a project costume. Legacy fields contain values that no longer mean what the schema says, duplicates that were never merged, and dates that encode business rules nobody documented.

Profiling a real extract is the only reliable control. Take 100,000 rows, count nulls, distinct values, orphans, and out-of-range values, and compare against the migration rules. The output is a conversion rate — say 94% automatic, 5% needing rules, 1% needing human decisions — which converts directly into effort and a realistic cutover date.

Dependency and vendor risk

Every technology project depends on something it does not control: a cloud region, an open-source library, a payment provider, a data supplier. The risks are licence changes, deprecations, price moves, outages, and disappearance.

A 2022 CISQ finding shows the direction of travel: failures attributable to weaknesses in open-source components in the software supply chain increased by 650% between 2020 and 2021. The control is not to avoid dependencies — that is impossible — but to know which are load-bearing, pin versions, monitor advisories, and keep an exit path for the two or three you could not replace in a week.

How do you turn a technology risk into a testable control?

You write the test before the mitigation, and you attach a threshold, an owner, and a date. This is the single practice that separates a risk register from a wish list.

The control pattern

For each risk, write four lines:

• Claim being tested. “The vendor API supports idempotent retries on payment creation.”
• Test. “Send 500 duplicate requests with the same idempotency key to the sandbox and count distinct charges.”
• Pass condition. “Exactly 500 requests produce 1 charge, with 0 duplicates and 0 errors.”
• Owner and date. Named person, specific date, before the build depends on it.

A control without a pass condition cannot fail, which means it cannot inform a decision. Vague controls are worse than none, because they consume the credibility a real test would have earned.

Worked example: the integration that looked fine

A payments team plans to connect its checkout service to a new provider. The plan assumes integration takes three weeks. A two-day spike against the sandbox reveals three facts: the provider does not support idempotent retries, its settlement report arrives 26 hours late, and its sandbox rejects the currency format used in two of the four target markets.

Cost of the spike: 2 engineers × 2 days × $800 per day = $3,200.

Cost had this surfaced in week 14, after the checkout flow, reconciliation job, and market rollout were built on the assumption:

• Rework of retry handling: 15 engineer-days × $800 = $12,000
• Reconciliation rebuild: 20 engineer-days = $16,000
• Delay of two market launches by three weeks, at $40,000 weekly contribution margin each = $240,000

The ratio is roughly 1:84. That number is the argument for spikes, and it is why the honest comparison is never “spike versus no spike” but “spike now versus rework later”.

Worked example: what a load test buys

An order service is specified at 1,200 requests per second with p95 latency under 300 ms. The team tests at 1,200 rps in week 6 rather than week 20.

• p95 comes back at 410 ms, with connection pool exhaustion at 900 rps.
• Fix one: raise the pool from 20 to 60 connections and add a queue — 4 engineer-days, $3,200.
• Fix two: add an index that removes a table scan — 2 engineer-days, $1,600.
• Retest in week 7: p95 of 240 ms at 1,400 rps, passing.

Total: $4,800 and one week. The same two defects found in a pre-launch hardening phase, with six dependent services already tuned around the slow behaviour, cost three to five times as much in rework plus the schedule slip — and they are found under deadline pressure, which is when teams make their worst architectural compromises.

What belongs in a technology risk register?

Keep the register short and testable. Ten to twenty rows is enough for most projects; a hundred rows means nobody is reading it.

Two fields do the most work. Test / evidence forces the team to say how they know. Trigger turns the risk into something that fires automatically rather than waiting for someone to notice.

How much should you spend on de-risking?

Spend up to the expected loss, and no more. Expected loss = probability × impact.

Suppose an unproven streaming platform has a 30% chance of failing the throughput requirement. If it fails, the fallback costs 40 engineer-days at $800, or $32,000, plus a four-week delay worth $60,000. Total impact: $92,000.

• Expected loss: 0.30 × $92,000 = $27,600
• Cost of a spike to resolve the uncertainty: 1 engineer × 10 days × $800 = $8,000

The spike is worth roughly three times its cost in avoided expected loss, and it produces information you keep. When the expected loss is small — say $4,000 — a two-week investigation is not justified; accept the risk, write down the acceptance, and move on.

> Common mistake: Treating “we have a risk register” as risk management. A register with no tests, no triggers, and no owners is a list of anxieties with a version number. The value is in the evidence column.

When should you not de-risk?

The last row matters more than it looks. Many “technical” risks are contractual or organisational: an interface nobody owns, a support tier that excludes the failure you are worried about, a data-sharing agreement that forbids the test you need. No amount of engineering removes those.

What are the common mistakes?

Testing at the end because the environment is finally ready. The environment is never ready. Build a minimal test harness early; it is cheaper than the rework.

Confusing a demo with evidence. Vendor demos run on curated data with a captive audience. Evidence runs on your data, your volume, and your failure cases.

Writing risks without thresholds. “Performance may be an issue” cannot be closed. “p95 above 300 ms at 1,200 rps” can.

Letting the risk owner be the person who built the assumption. Independent verification is not bureaucracy; it is the difference between a test and a confirmation.

Treating security as a gate. A gate at the end is a decision to either delay or accept a known flaw. Both are expensive; neither is a control.

Where does project tooling help?

Technology risk management fails on traceability more often than on analysis. The spike verdict lives in a document, the load-test result in a chat thread, the risk in a spreadsheet, and the mitigation task in a tracker.

Doitify keeps tasks, sub-tasks, checklists, dependencies, project documents, and a risks-and-constraints record in one workspace, so a risk entry can carry its test, evidence, and the task that closes it. Dependency views show which build tasks sit downstream of an unproven assumption, and workload views show whether the evidence owner has time to produce it. Doitify is our product, so read this as a description of fit: a team with a working register and a shared document store does not need to move anything.

Conclusion

Technology project risks are not mysterious. They are specific claims about how systems behave, and claims can be tested. The projects that suffer are rarely the ones that took too long to test; they are the ones that tested last.

Name the six families, pick the four or five that apply, and convert each into a test with a threshold, an owner, and a date in the first third of the schedule. Price the exposure with probability × impact so the spend is defensible. Then write down what you deliberately accepted, because an accepted risk with a rationale is a decision, while an ignored risk is a surprise waiting for a date.

If this post on technology project risks was helpful, you might also enjoy How to Calculate the Critical Path (Step-by-Step) and Best Project Management Views: List, Board, Gantt or Calendar?.