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

## Why it matters

In your agile course you learned how Scrum and Kanban teams deliver in small increments. In the real IT world, few projects are purely agile. A project to replace a clinic's booking system might include a software build (well suited to sprints), a hardware purchase with a six-week lead time, a data migration that has to happen on one weekend, and a regulator who wants a signed test report before go-live. A project lead's first big decision is **how** to deliver each part, and the honest answer is often "a bit of both".

This lesson gives you a practical way to choose, and the words to explain your choice to a sponsor.

## Three approaches

**Predictive** (often called waterfall or plan-driven) fixes scope early, plans the whole job up front and then executes the plan in phases: requirements, design, build, test, deploy. Change is possible but goes through formal change control. It works best when requirements are stable and well understood, when work must happen in a fixed order, or when mistakes are expensive to undo.

**Adaptive** (agile) fixes time and team size, and lets scope flex. The team delivers working increments every one to four weeks, gets feedback and re-plans. It works best when requirements are uncertain, users can give frequent feedback, and the product can be released in pieces.

**Hybrid** combines the two on purpose. Common patterns are:

- **Predictive shell, agile core.** Phase gates, a fixed budget and a launch date at the top; sprints inside the build phase.
- **Agile build, predictive rollout.** Features are built in sprints, but deployment to 40 sites follows a detailed cutover plan.
- **Workstream split.** The software team runs Scrum while the infrastructure, procurement and training workstreams run on a schedule.

Hybrid is not "agile without the discipline" or "waterfall with stand-ups". Each workstream should use the approach that fits it, and the plan should show how they connect.

## A simple way to choose

Ask five questions about each major piece of work. Score each one towards predictive (P) or adaptive (A).

| Question | Leans predictive | Leans adaptive |
|---|---|---|
| How stable are the requirements? | Known and agreed | Likely to change or be discovered |
| Can we deliver in usable pieces? | No: it is all or nothing | Yes: users can use part of it |
| How costly is a change late on? | Very (hardware, contracts, regulation) | Low (software behind a feature flag) |
| How available are users for feedback? | Rarely | Every week or two |
| What does governance require? | Signed designs and phase gates | Outcomes and regular demos |

If most answers lean one way, use that approach for that piece. If they split, use a hybrid and say which parts are which.

## Worked example: Northside Clinics booking portal

Throughout this course you will follow one project. **Northside Clinics**, a group of 12 clinics, is replacing its phone-only appointment booking with an online portal. The budget is $480,000 over nine months.

| Workstream | Assessment | Approach |
|---|---|---|
| Patient-facing portal | Requirements will change once patients try it; can release to one clinic first | Agile (two-week sprints) |
| Integration with the clinical records system | Vendor API is fixed, contract needs a defined scope | Predictive, with a fixed-scope statement of work |
| Kiosk hardware for waiting rooms | Six-week lead time, cannot change after ordering | Predictive |
| Staff training and rollout to 12 clinics | Depends on clinic calendars; must be scheduled | Predictive rollout plan, clinic by clinic |

So the project is a **hybrid**: one governance framework, one budget and one integrated schedule, with the portal team working in sprints. The integrated schedule shows the dependencies that matter: the portal cannot go live at a clinic until the integration is tested and the kiosks are installed there.

To explain this to the sponsor, keep it short:

> "We will build the portal in two-week sprints and show you working software every fortnight, because we expect to learn a lot from patients. The records integration and the kiosk order are fixed by contracts and lead times, so we will plan those in detail now. You will see one combined schedule and one status report."

## Making a hybrid work

- **Align cadences.** Hold steering meetings on a rhythm that matches sprint reviews, so the board sees real demos.
- **Use milestones as the bridge.** Predictive workstreams report against milestones; the agile team maps its release plan to the same milestones.
- **Keep one risk register and one change process.** Agile backlog changes inside the agreed scope do not need a change request; changes to budget, date or major scope do.
- **Agree what "done" means for each workstream** so that handoffs are clear.

## Common mistakes

- **Choosing by habit or fashion.** "We are an agile company" is not a reason to run a hardware order in sprints.
- **Two disconnected plans.** If the agile team and the infrastructure team plan separately, nobody sees the dependency until it breaks.
- **Fixed scope, fixed date, fixed budget and "agile".** Something has to flex. Say what.
- **Forgetting the people side.** Teams used to one approach need coaching to work alongside the other.

## Quick recap

- Predictive fits stable, sequential, costly-to-change work; adaptive fits uncertain work that can be delivered in pieces.
- Hybrid means choosing per workstream on purpose, inside one governance framework.
- Use a short set of questions to decide, then explain the choice in plain language.
- Connect workstreams with shared milestones, one risk register and one change process.

## Try it

Open the **Do** tab and answer the quiz to check you can pick an approach for different kinds of work.


Choose between predictive, agile and hybrid delivery for each part of an IT project, and explain the choice to a sponsor.

Hybrid and predictive delivery

Predictive vs Agile vs Hybrid

Project Management: Waterfall, Agile, & Hybrid Approaches

Name the person, their role and the specific thing you need from them, with a date.

Write down three things this person is likely to value or worry about right now. If you can, check by asking them or someone who knows them.

Write what your request costs them (time, risk, attention) in concrete terms.

List at least two things you can offer that match what they value (removing effort, visibility, solving one of their problems).

Write the request in four sentences or fewer: the problem, why it matters, exactly what you need, and what you have already done to make it easy.

Decide what you will do if they say no: a smaller ask, a different date, or an escalation of the decision (not the person). Write who you would escalate to and how you would tell the person first.

If it is a real situation, have the conversation and note what happened.

## Why it matters

Most IT project managers lead people who do not report to them. The developers report to an engineering manager, the database administrator belongs to the infrastructure team, the security reviewer works for the CISO and the vendor answers to their own account manager. You cannot order any of them to do anything. Yet you are accountable for the project getting delivered.

This is called **leading without authority**, and it is the core skill of the job. The good news is that it can be learned. It rests on three things: understanding what other people value, building trust before you need it, and making it easy for people to help you.

## Power you do have

You may not have positional power, but you usually have other sources of influence:

- **Information.** You see the whole project. You know what is blocked, what is late and what the sponsor cares about.
- **Relationships.** You talk to everyone. People who trust you will go out of their way for you.
- **Expertise.** Being good at planning, running meetings and removing obstacles makes people want to work with you.
- **Reflected authority.** The sponsor's goals are behind you, but use this rarely. "The VP said so" works once and costs trust.

## Exchange: what does each person value?

A useful idea from Allan Cohen and David Bradford's work on influence is that cooperation runs on **exchange**. People help those who help them, though the "currency" is not always obvious. Before you ask someone for something, ask yourself what they value.

| Person | What they might value | What you can offer |
|---|---|---|
| Senior developer | Interesting problems, fewer interruptions, being heard on design | Protect focus time, bring them into decisions early, credit their work publicly |
| Engineering manager | Predictable demands on their team, career growth for their people | Give early notice of needs, a clear scope, visibility for their team's work |
| Security reviewer | Being involved before it is too late to fix things | Invite them to design reviews, give them time in the plan |
| Vendor account manager | A smooth, referenceable customer | Clear requirements, prompt decisions, fair escalation |

When you frame a request in terms of what the other person values, it stops being a favour and becomes a fair trade.

## Building trust before you need it

Trust comes from **reliability** (you do what you say), **honesty** (you share bad news early) and **care** (you treat people's time and goals as real). Practical habits:

- Meet each key person one to one early in the project, before there is a problem. Ask what success looks like for them and what worries them.
- Keep small promises: send the notes when you said you would.
- Never surprise anyone in public. If a status report will show their work as red, tell them first.
- Give credit loudly and take blame quietly.

## Making it easy to say yes

A clear, specific request is much easier to agree to than a vague one.

Weak: "Can someone look at the integration issue?"

Strong: "Priya, the records API returns a timeout on the bulk export, which blocks the clinic data load planned for 14 March. Could you spend an hour with the vendor's engineer on Thursday to diagnose it? I have booked the call and sent them the logs."

The strong version says what the problem is, why it matters, exactly what is needed, and what you have already done to reduce the effort.

## Worked example: getting a busy team's time

On the Northside Clinics project, the portal needs a change to the single sign-on configuration. That belongs to the identity team, who are busy with an audit and have no reason to prioritise you.

1. **Understand them.** You learn their audit is about access reviews, and their manager, Tom, is worried about finishing it on time.
2. **Find the exchange.** The portal will remove 300 shared clinic logins, which reduces Tom's audit findings. That is something Tom values.
3. **Make the ask concrete.** "The portal can retire the shared logins at all 12 clinics. To do that we need one SSO application set up by 1 April, about four hours of work. Our developer can draft the configuration for your review so your team only checks and applies it."
4. **Follow through.** Send the draft on time, thank the team in the steering report, and mention the retired logins in Tom's audit.

## When influence is not enough

Sometimes a conflict of priorities cannot be solved between peers. Escalation is then a normal, healthy step, not a failure. Do it well:

- Tell the other person first that you plan to escalate, and why.
- Escalate the **decision**, not the person: "Team A and the portal both need Priya in March. Which comes first?"
- Bring options and the impact of each.

## Common mistakes

- Using the sponsor's name as a threat.
- Asking for help only when you are in trouble.
- Vague requests that make the other person do the thinking.
- Treating engineers as resources to be scheduled rather than experts to be consulted.

## Quick recap

- Most project leads have no direct authority; influence comes from information, relationships and expertise.
- Find what each person values and frame requests as a fair exchange.
- Build trust early with reliability, honesty and no public surprises.
- Make requests specific and low-effort; escalate decisions, not people, when needed.

## Try it

Open the **Do** tab and plan how you would influence one real or realistic person who does not report to you.


Influence engineers, managers and vendors who do not report to you by understanding what they value and building trust.

Leading without authority

Leading without authority | Mary Meaney Haynes | TEDxBasel

How To Be a Leader When You're Not the Boss

List the steering committee members and, for each, what they care about most.

Write a tolerance table for schedule, cost and scope with three levels: project lead, sponsor and committee.

Write a three-sentence summary with an honest overall RAG status and the reason for it.

Write at least one decision request with two or more options, the cost and impact of each, and your recommendation.

Add a milestone table (planned vs forecast) and a short financial line (budget, actual, forecast).

List the top three risks or issues, each with an owner and the next action.

Read the first page as if you were the sponsor with two minutes to spare. Cut anything that does not help them decide.

## Why it matters

As projects grow, the question "who decides?" becomes as important as "what do we build?". Without clear governance, decisions stall, the project lead makes calls they have no right to make, or every small change ends up on an executive's desk. **Project governance** is the set of roles, rules and meetings that decide how a project is directed and controlled. The **steering committee** is usually where the big decisions happen, and the pack you prepare for it is one of your most important documents.

## Roles in a typical IT project

- **Sponsor.** Owns the business case and is accountable for the benefits. Chairs the steering committee. Has the final say on scope, budget and date within their authority.
- **Steering committee.** Senior people whose areas are affected: for Northside Clinics, the operations director, the head of IT, the clinical lead and finance. They give direction, make decisions above the project lead's tolerance, and remove obstacles.
- **Project lead (you).** Runs the project day to day within agreed tolerances. Prepares information, recommends options and carries out decisions.
- **Workstream leads and product owner.** Make decisions inside their area, such as backlog order.
- **Assurance** (sometimes a PMO, risk or audit function). Checks independently that the project is being run properly.

## Decision rights and tolerances

The most useful governance tool is a short list of **tolerances**: how far the project can deviate before it must be escalated. For example:

| Dimension | Project lead can approve | Sponsor can approve | Steering committee decides |
|---|---|---|---|
| Schedule | Up to 1 week slip on a milestone | Up to 4 weeks | More than 4 weeks, or the go-live date |
| Cost | Up to $5,000 within the contingency | Up to $25,000 | More than $25,000 |
| Scope | Backlog changes inside agreed features | Swapping features of similar size | Adding or removing a major feature |
| Risk | Low and medium risks | High risks with a plan | Any risk that threatens the business case |

When a forecast goes beyond a tolerance, you raise an **exception**: you tell the next level up, with options, before the limit is actually breached. This is "management by exception": senior people do not need to approve everything, only what goes outside the agreed limits.

## Stage gates

Predictive and hybrid projects often have **stage gates**: points where the committee reviews progress and decides whether to continue. A gate asks:

1. Is the business case still valid?
2. Did we deliver what this stage promised?
3. Is the plan for the next stage realistic, and are the risks acceptable?
4. Go, go with conditions, re-plan, or stop?

Stopping a project at a gate is a success of governance, not a failure, if the business case no longer holds.

## The steering committee pack

A good pack is short, honest and built around decisions. Busy executives may read only the first page, so put the decisions there. A typical structure:

1. **Summary and decisions required** (half a page). Overall RAG status, the one-paragraph story, and each decision needed with your recommendation.
2. **Progress against milestones.** Planned vs forecast dates.
3. **Financials.** Budget, actual, forecast and contingency used. Earned value indices if you track them (next module).
4. **Top risks and issues.** No more than five each, with owners and actions.
5. **Change requests** awaiting approval, with impact.
6. **Appendix.** Detail for those who want it.

## Worked example: a decision page

> **Northside Clinics booking portal: steering committee, 3 June**
>
> **Overall status: Amber.** Portal sprints are on track (pilot clinic live 20 May, 1,140 bookings in two weeks). The records integration is three weeks late because the vendor's test environment was unavailable.
>
> **Decision 1: rollout schedule.** The integration delay pushes the 12-clinic rollout from 1 August to 22 August.
> - Option A: accept the new date. No extra cost. Recommended.
> - Option B: keep 1 August by adding a second vendor engineer: +$18,000, and the rollout happens during the clinics' busiest fortnight.
>
> **Decision 2: kiosk numbers.** Pilot data shows 70% of patients book on their own phones. We recommend reducing kiosks from 24 to 12, saving $21,000.

Notice that each decision has options, costs, a recommendation and evidence. The committee can decide in minutes.

## Running the meeting

- Send the pack two working days before the meeting.
- Brief the sponsor beforehand so there are no surprises.
- Spend the meeting on decisions and risks, not reading the report aloud.
- Record decisions, owners and dates in minutes, and circulate them within a day.

## Common mistakes

- **Watermelon reporting**: green on the outside, red inside. Report the real status.
- Packs of 40 slides with no decision asked for.
- No tolerances, so everything or nothing gets escalated.
- Steering committees with no one who can actually commit budget or people.

## Quick recap

- Governance defines who decides what; the sponsor owns the business case.
- Tolerances let the project lead manage within limits and escalate exceptions early.
- Stage gates check that the business case still holds before more money is spent.
- A steering pack leads with decisions, options and recommendations.

## Try it

Open the **Do** tab and build a one-page steering committee pack for a project.


Set up decision rights, tolerances and escalation for a project, and prepare a steering committee pack that gets decisions made.

Governance and steering

What is Project Governance? [CLEAR BREAKDOWN]

What is a Steering Committee [PURPOSE AND ROLES EXPLAINED]

Choose predictive, agile or hybrid delivery, influence people who do not report to you, and set up governance and steering committees.