Lead mid-size IT projects: hybrid delivery, governance, earned value, vendors, business cases, technical and security risk, recovery and your path to PMP and program management.

IT Project Leadership

Pick five questions from the lesson (include "What is the riskiest assumption?" and "What have we not tested against the real system yet?").

Hold a 20 to 30 minute conversation one to one. Explain that you want to find problems early, not blame anyone.

Write down every risk mentioned, in the engineer's own words.

Turn the two most important ones into risk statements: "Because [cause], [event] may happen, which would [impact]."

For each, agree an owner and a concrete response, such as a time-boxed spike, a walking skeleton or a vendor question.

Translate one risk into two plain-English sentences for a non-technical sponsor, stating the impact on time, cost or users.

Thank the engineer and send them your notes to check you understood correctly.

## 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.


Spot the technical risks that sink IT projects and ask engineers the questions that bring them to the surface early.

Technical risk for PMs

Project Risks vs Development Risks | Technical Project Managers

Project Risk Management - How to Manage Project Risk

## Why it matters

Security and privacy problems found the week before go-live are among the most expensive surprises an IT project can have. A penetration test that finds serious flaws, a privacy review that says you cannot store certain data, or an auditor asking for evidence you never collected can each delay launch by weeks. Worse, problems that reach production can harm real people and bring fines. The fix is simple to describe: plan security and compliance as **gates** in the project from the start, with time and owners, just like testing. This is often called "shifting left" or **security by design** and **privacy by design**.

You are not expected to be the security expert. You are expected to involve the experts early, give them time in the plan, and make sure their requirements are treated as real requirements.

## Which rules apply?

Ask your security, privacy and legal teams early which laws, regulations and standards apply. Common ones for IT projects include:

- **Privacy laws** such as the EU and UK GDPR, and state laws such as the California Consumer Privacy Act (CCPA). These set rules on collecting, using, keeping and deleting personal data.
- **Sector rules**, for example HIPAA for health information in the US, or PCI DSS if the system handles payment card data.
- **Assurance frameworks** customers may ask for, such as SOC 2 reports or ISO/IEC 27001 certification.
- **Accessibility** requirements (for example WCAG conformance in public-sector contracts) are often handled alongside compliance.
- **Internal policies**: data classification, retention, approved cloud providers, change management.

The details of these rules change and depend on where you operate. Do not interpret them yourself: record the requirement, name an owner in the relevant team, and plan the work.

## Security and privacy gates across the lifecycle

| Phase | Gate or activity | Typical owner |
|---|---|---|
| Initiation | Data classification: what data will we handle? Is personal or sensitive data involved? | Product owner with privacy team |
| Initiation | Privacy impact assessment (a DPIA under GDPR) if personal data is high risk | Privacy officer |
| Requirements | Security and privacy requirements written as backlog items or requirements, with acceptance criteria | Security architect, business analyst |
| Design | Architecture and **threat modelling** review: how could this be attacked? | Security architect, lead engineer |
| Vendor selection | Vendor security questionnaire, contract clauses (data processing agreement, breach notification) | Procurement, security |
| Build | Secure coding practices, code review, automated scanning of code and dependencies | Engineering team |
| Test | Security testing, and a penetration test for internet-facing systems | Security team or external testers |
| Go-live | Security sign-off, access reviews, logging and monitoring in place, incident response contacts | Security, operations |
| Closure | Evidence filed for auditors; retention and deletion rules working | Project lead, compliance |

## Worked example: Northside Clinics

The portal handles patient names, contact details and appointment types, which is health-related personal data. At initiation, you:

1. Ask the privacy officer whether a privacy impact assessment is needed. It is, and it takes three weeks, so it goes on the critical path before design sign-off.
2. Add security requirements to the backlog: multi-factor sign-in for staff, encryption in transit and at rest, audit logs of who viewed which booking, and deletion of cancelled bookings after the agreed retention period.
3. Book an external penetration test six weeks before go-live, with two weeks after it reserved for fixes.
4. Make sure the kiosk vendor contract includes a data processing agreement and breach notification terms.

When the penetration test finds one high-severity issue, there is time to fix and retest without moving the launch.

## Data minimisation: the cheapest control

The safest data is data you never collect. Ask, for each field: do we need it, for how long, and who needs to see it? The Northside team dropped date of birth from the booking form for returning patients because the records system already had it, which removed a privacy risk at zero cost.

## Common mistakes

- Booking the penetration test the week before go-live, with no time to fix findings.
- Treating security requirements as "non-functional" extras that get cut when time is short.
- Copying production data, including real personal data, into test environments without approval.
- Assuming a cloud provider handles all compliance. Under the **shared responsibility model**, the provider secures its infrastructure; you remain responsible for how you configure and use it.

## Quick recap

- Plan security and privacy as gates with owners and time, from initiation to closure.
- Ask the experts which laws and standards apply; record them as requirements.
- Threat model in design, scan and review in build, penetration test with time to fix.
- Collect only the data you need, and keep evidence for auditors.

## Try it

Open the **Do** tab and test yourself on where security and compliance fit in a project.


Build privacy and security gates into an IT project plan from the start, and know which laws and standards to ask about.

Security and compliance in projects

What makes a secure SDLC? | AppSec 101

CertMike Explains Privacy by Design

List the evidence that the project is in trouble (dates, money, quality, people). Use numbers where you can.

Write the stabilise actions you would take in the first week, including what you would freeze.

List the five people you would interview first and one question you would ask each.

Identify at least two likely root causes, and for each, how you would confirm it.

Describe three options (for example reduce scope, move the date, change approach, stop) with the impact of each on scope, time and cost.

Choose one option and write the new milestones for the next eight weeks, including at least one small early win.

Write how reporting and governance will change so the same problems do not return.

## Why it matters

Sooner or later you will lead a project that is in trouble, or be asked to take over one that is. The signs are familiar: dates keep slipping, the budget is mostly spent but the product is not close to done, the team is exhausted, and the sponsor has stopped believing the status reports. Recovering a troubled project is a distinct skill. It is not about working harder: it is about stopping the slide, finding out what is really happening, making hard trade-offs openly and rebuilding trust with a plan people believe.

## Signs a project is in trouble

- Repeated milestone slips, each "just two more weeks".
- CPI and SPI well below 1 and not improving.
- Scope that keeps growing without change control.
- Rising defect counts and falling team velocity.
- Key people leaving or burned out.
- Status reports that are green while everyone privately knows otherwise ("watermelon" status).

## A recovery process in five steps

**1. Stabilise.** Stop making the situation worse. Freeze new scope. Pause any work that is not clearly valuable. Agree with the sponsor that you have, say, two weeks to assess before committing to new dates. Do not promise a date before you know the facts.

**2. Assess.** Find out what is true. Talk to the team, the sponsor, users and vendors one to one. Review the plan, the backlog, the defect list, the budget and the contracts. Ask:

- What is actually finished, tested and usable?
- What is the real remaining work, estimated by the people who will do it?
- What are the root causes: unclear scope, poor estimates, technical problems, missing skills, weak governance, vendor issues?
- Is the business case still valid?

**3. Decide.** Present the facts and options to the steering committee. Typical levers, often combined:

- **Reduce scope** to a minimum viable release: what must launch, what can wait.
- **Move the date.**
- **Add budget or people** (be careful: adding people late often slows things down at first while new people learn).
- **Change the approach**, for example switching the build to short iterations with demos to rebuild visibility.
- **Stop the project** if the business case no longer holds.

**4. Re-plan.** Create a new baseline from bottom-up estimates, with contingency, clear milestones and tighter tracking. Fix the root causes, not just the symptoms: if the problem was uncontrolled change, put change control in place.

**5. Rebuild trust.** Report honestly and frequently. Hit the first few new milestones, even small ones. Celebrate progress with the team. Trust comes back from evidence, not promises.

## Worked example: rescuing the Northside integration

Imagine that by month 6, the records integration has slipped three times, the vendor and the in-house team blame each other, and CPI is 0.78. You are asked to take over.

- **Stabilise:** you freeze two "nice to have" portal features and agree a two-week assessment with the sponsor.
- **Assess:** interviews show the root cause: the fixed-price SOW never specified who provides test data, so each side waited for the other. Only two of six interfaces are fully tested. Bottom-up estimates put the rest at seven weeks.
- **Decide:** you present three options. The committee chooses option B: launch with four interfaces (booking, cancellation, reminders, patient lookup) and deliver the two reporting interfaces one month after launch. Go-live moves by three weeks instead of seven.
- **Re-plan:** a contract amendment names Northside as the provider of anonymised test data within five days of each request. Weekly integration demos replace monthly status calls.
- **Rebuild trust:** the first interface passes testing on the new date, and you report it with evidence.

## The recovery plan document

Keep it short. A useful structure:

1. Current situation: honest summary with data.
2. Root causes.
3. Options considered and the recommended option.
4. New scope, schedule and budget baseline.
5. Changes to how the project is run (governance, change control, reporting cadence).
6. Top risks of the recovery itself.
7. Decisions needed now.

## Common mistakes

- Announcing a new date before assessing.
- Blaming individuals instead of fixing causes.
- Keeping full scope and "working harder": that is how the project got here.
- Adding many people at once.
- Hiding the recovery from the sponsor until it is "under control".

## Quick recap

- Recovery follows stabilise, assess, decide, re-plan, rebuild trust.
- Base decisions on facts and root causes, gathered one to one.
- Trade scope, time, budget and approach openly; stopping is a valid option.
- Trust is rebuilt by hitting small, honest milestones.

## Try it

Open the **Do** tab and write a recovery plan for a troubled project.


Diagnose a troubled IT project, reset scope and plan with stakeholders, and write a recovery plan that rebuilds trust.

Recovering a troubled project

The Project Recovery Process: How Do You Turn a Project Around?

Surface technical risk early, plan security and privacy gates, and recover a project that is in trouble.