Spot the technical risks that sink IT projects and ask engineers the questions that bring them to the surface early.
Why it matters
You do not need to be able to write the code to lead an IT project, but you do need to understand where technical work goes wrong. Most late and over-budget IT projects fail on a handful of predictable technical risks: integrations that do not behave as documented, data that is dirtier than expected, performance that collapses under real load, and environments that are not ready. Engineers usually know about these risks early. Your job is to ask the questions that bring them into the open while they are still cheap to deal with, and to give the team time in the plan to reduce them.
The usual suspects
| Risk area | What goes wrong | Early warning signs |
|---|---|---|
| Integration | Third-party APIs differ from their documentation, have rate limits or slow test environments | "We haven't called the real API yet" |
| Data migration | Old data has duplicates, missing fields and odd formats; volumes are larger than thought | No one has profiled the source data |
| Performance and scale | Works for 10 test users, fails at 8 a.m. on Monday with 2,000 | No load test in the plan |
| Environments | Test and staging environments late, different from production | "It works on my machine" |
| New technology | The team is learning a framework or cloud service as they go | Estimates with wide ranges, or none |
| Technical debt | Old code is fragile; every change breaks something else | Rising bug counts, slower velocity |
| Security and access | Firewall rules, certificates and permissions take weeks to approve | Access requests not yet raised |
| Key-person dependency | Only one person understands a critical system | Same name on every task |
Questions that surface risk
Engineers often answer exactly the question you ask. "Are we on track?" gets "yes". Better questions are specific and safe to answer honestly:
- "What is the riskiest assumption in this design?"
- "What have we not tested against the real system yet?"
- "If this estimate turns out to be wrong, which part is most likely to be the reason?"
- "What would have to be true for us to hit the date? Which of those are you least sure about?"
- "What does the rollback plan look like if the release goes wrong?"
- "Who else would we need if you were off sick for two weeks?"
- "What are you waiting on from outside the team?"
- "Is there anything you think I should be worried about that I'm not asking about?"
Ask these in a calm one-to-one or a risk session, not in front of the sponsor. Thank people for bad news, otherwise you will stop hearing it.
Ways to reduce technical risk
- Spikes. A short, time-boxed investigation (one to three days) to answer a technical question before committing to an estimate. "Can we pull a full day's appointments from the records API in under five minutes?"
- Walking skeleton. Build a thin end-to-end slice early: one screen, one API call, one database write, deployed to a real environment. It flushes out integration and environment problems in week three instead of month six.
- Profile the data before you plan the migration. Run counts of nulls, duplicates and formats.
- Load test before go-live with realistic volumes.
- Feature flags and phased rollout so a problem affects one clinic, not twelve.
- Pairing and documentation to spread knowledge away from one person.
These activities cost time, so put them into the plan and explain them to the sponsor: a two-day spike that avoids a two-month surprise is good value.
Worked example: the Northside Clinics integration
In sprint 2, you hold a 30-minute risk session with the integration developer, Priya. You ask: "What have we not tried against the real system yet?" She says the vendor's sandbox only has 50 fake patients, but production has 180,000 records, and the documentation does not mention paging.
You record a risk:
Risk T-04. Because the records API's behaviour with large result sets is untested, the nightly appointment sync may time out at production volumes, which would delay rollout by two to four weeks. Likelihood: medium. Impact: high. Owner: Priya. Response: three-day spike in sprint 3 against the vendor's performance environment; raise a vendor support ticket now.
The spike finds that the API needs paging and has a rate limit of 10 calls per second. The team redesigns the sync before building it. Cost: three days. Avoided: a failed go-live.
Translating for non-technical stakeholders
Sponsors need impact, not jargon. Translate:
- Not "the API lacks pagination support", but "the records system only gives us data in small pieces, so the overnight update needs a redesign: three extra days now, which removes a risk of a month's delay later."
Common mistakes
- Treating the engineers' estimate as a commitment instead of a forecast with uncertainty.
- No time for spikes, testing or environments in the plan.
- Asking "any risks?" in a big meeting and taking silence as "no".
- Logging technical risks with no owner or response.
Quick recap
- A few technical risk areas (integration, data, performance, environments, new tech, debt, access, key people) cause most IT project problems.
- Ask specific, safe questions and reward honest answers.
- Reduce risk early with spikes, a walking skeleton, data profiling, load tests and phased rollout.
- Translate technical risks into impact on time, cost and users.
Try it
Open the Do tab and run a short technical risk interview.