Managing Projects with AI

Most engineering projects don’t fail because engineers can’t build the solution. More often, they struggle because the problem was never fully clear, stakeholders had different expectations, dependencies emerged later than expected, ownership was ambiguous, or the project slowly drifted from its original goal.

For me, project management is mostly about reducing that uncertainty. The size of the project can change from a small initiative owned by one engineering team to a large migration involving multiple teams and stakeholders. However, the fundamentals tend to stay the same.

I like to think about a project in four phases:

Initiation → Planning → Execution → Closing

AI doesn’t replace any of these phases, and I don’t think that should be the objective. What it can do extremely well is reduce the administrative overhead around them, help challenge assumptions, summarise large amounts of information, identify risks we may have missed, and make it easier to keep everyone aligned.

The goal is not to let AI manage the project. The goal is to use AI as a project management copilot.

1. Initiation

The initiation phase should answer one fundamental question:

Should we do this project, and do we understand what we are trying to achieve?

This sounds obvious, but it is surprisingly common to jump directly into implementation. Someone creates an Epic, engineers start investigating possible solutions, meetings start appearing on calendars, and a few weeks later someone asks what problem the project is actually solving.

Before thinking about implementation, we want to understand a few basics: what we are trying to achieve, why we are doing it, who benefits, when it needs to happen, and where the change applies.

More importantly, we need a shared definition of success.

Imagine a fictional project where the goal is to migrate an experimentation platform from a legacy solution to a new platform. The output sounds simple enough: migrate all experiments. However, that does not really tell us whether the project succeeded.

A better definition might be:

By the end of Q4, 95% of active experiments use the new experimentation platform, all product teams can independently create experiments, experiment assignment adds less than 10ms latency, and the legacy platform can be decommissioned.

Now the project has something measurable behind it, which makes future conversations about scope, priorities and trade-offs much easier.

Define the scope

Projects need clear boundaries. If we continue with the experimentation migration example, the scope could look like this:

In scope

• New experimentation SDK
• Backend integration
• Data pipeline
• Migration documentation
• Team onboarding
• Existing experiment migration

Out of scope

• Rebuilding the experimentation UI
• Changing the company’s experimentation methodology
• Migrating historical experiment data

The “out of scope” section is particularly useful because without it, every reasonable adjacent idea has a tendency to become part of the project. That is usually how scope creep begins: not with one obviously unreasonable request, but with a series of individually sensible additions.

Understand the stakeholders

A technical project can have a surprisingly large number of stakeholders, and they often care about very different things.

One technique I like is asking several stakeholders independently:

How would you describe this project, and what does success look like to you?

If the answers differ significantly, that is useful information. It usually means the project is not yet ready for detailed planning because the organisation has not aligned on the problem.

The Project Charter

The main output of initiation should be a lightweight Project Charter. It doesn’t need to be a large document, but it should be good enough to give the team and stakeholders a shared source of truth.

# Project Charter

## Summary
What are we building or changing?

## Problem
What problem are we trying to solve?

## Goals
What outcomes do we want?

## Success Metrics
How will we know the project succeeded?

## Scope
What is included?

## Out of Scope
What is explicitly excluded?

## Stakeholders
Who is affected or involved?

## Benefits
What value will this project create?

## Costs
Engineering time, infrastructure, money, opportunity cost.

## Constraints
Deadlines, regulatory requirements, technical limitations.

## Known Risks
What could prevent us from succeeding?

The charter should be short enough for a senior stakeholder to read in a few minutes, but useful enough that the team can refer back to it as the project becomes more complex.

Using AI during initiation

AI is particularly useful during this phase because the problem is still ambiguous, and its most valuable role isn’t generating polished documentation, but helping us discover what we haven’t thought about yet.

Instead of asking:

Create a project charter for this project.

I prefer giving AI the available context and asking it to challenge the project.

You are reviewing a new engineering project.

Here is the current project context:

[PASTE CONTEXT]

Act as a critical engineering leader.

Identify:
1. Unclear goals
2. Missing success metrics
3. Hidden assumptions
4. Potential scope ambiguity
5. Missing stakeholders
6. Major technical or organisational risks
7. Questions that should be answered before planning begins

Do not invent information. Separate facts, assumptions and open questions.

This is one of the most useful ways to use AI in project management. The value is often not in generating the answer, but in generating better questions.

2. Planning

Once we understand what we are trying to achieve, the planning phase answers the next question:

How are we going to get there?

This is where the project becomes operational. The high-level goal is broken down into milestones, deliverables, tasks, ownership, and dependencies.

A useful mental model is:

Goal → Milestones → Deliverables → Tasks

For the experimentation migration example, the project might have the following milestones:

M1 — New SDK production ready
M2 — Data pipeline validated
M3 — First three teams migrated
M4 — Organisation migration complete

Each milestone should represent a meaningful change in the project’s state. I try to avoid milestones such as “Backend work” because that describes an activity rather than an outcome. Something like “Backend supports production experiment assignment” is much better because it gives us a clear, verifiable point.

Dependencies

Dependencies are one of the biggest sources of project delays, especially in projects involving multiple teams.

The migration could look roughly like this:

SDK ready
   ↓
Data pipeline integration
   ↓
First experiment
   ↓
Migration documentation
   ↓
Team onboarding
   ↓
Organisation rollout

If the SDK slips by two weeks, several downstream milestones will likely slip as well. Identifying those relationships early makes it possible to understand the project’s critical path and focus attention on what can genuinely delay delivery.

For each important dependency, we should know:

Dependency:
Owner:
Needed by:
Current status:
Impact if delayed:
Mitigation:

A dependency without an owner is usually just a future problem waiting to happen.

Estimation

Project estimates are uncertain by definition, so I try not to ask teams for a single number without understanding what sits behind it.

Instead of asking:

How long will this take?

We would rather break the work down.

Build SDK interface            1 week
Implement provider adapter     1 week
Integration testing            1 week
Observability                  3 days
Documentation                  2 days
Production validation          3 days

Once we have that breakdown, we can challenge the assumptions. Are the right engineers available? Is another team required? Is the external API stable? Has the team built something similar before? Is there hidden review or approval work that is not represented in the estimate?

The objective is not to magically predict the exact delivery date. It is to understand where the uncertainty lives.

Ownership

Every important deliverable needs a clear owner. For larger projects, a lightweight RACI can be useful.

In practice, the two columns we care most about are Responsible and Accountable. Who is doing the work, and who ultimately makes sure it happens?

The Project Plan

At this point, the project charter can evolve into a more detailed project plan.

# Project Plan

## Owners
Project Lead:
Technical Lead:
Product Lead:

## Project
Name and short description.

## Goal
What outcome are we trying to achieve?

## Success Metrics
How do we measure success?

## Milestones

| Milestone | Owner | Target | Status |
|-----------|-------|--------|--------|
| M1 | X | Date | 🟢 |
| M2 | Y | Date | 🟢 |

## Dependencies

| Dependency | Owner | Needed By | Status | Impact |
|------------|-------|-----------|--------|--------|

## Risks

| Risk | Probability | Impact | Mitigation | Owner |
|------|-------------|--------|------------|-------|

## Communication
Weekly project update
Bi-weekly stakeholder review
Monthly leadership update

## Links
Technical design
Jira Epic
Dashboard
Decision log

The project plan should become the source of truth for how the project fits together. Jira (or any other tool) is still useful for tracking individual pieces of work, but a list of tickets is not the same thing as a project plan.

Using AI during planning

Planning is a good stage to use AI as a reviewer, especially for identifying hidden dependencies, missing milestones and weak assumptions.

You are reviewing the following engineering project plan:

[PASTE PROJECT PLAN]

Analyse the plan as a senior engineering program manager.

Identify:

1. Missing milestones
2. Milestones without measurable outcomes
3. Dependencies that may not be explicit
4. Work without clear ownership
5. Risks that are not documented
6. Unrealistic sequencing
7. Potential critical-path items
8. Areas where the delivery estimate has weak assumptions

Return:
- Findings
- Questions for the team
- Suggested changes

Do not change the plan automatically.

The final instruction is useful because AI should propose changes, but the team should remain responsible for making the decisions.

3. Execution

Execution is where the project plan meets reality, and reality tends to be more complicated than the original plan. People go on holiday, get sick, priorities change, an API behaves differently than expected, a dependency slips, or requirements evolve once real users and systems become involved.

Because of that, execution is not just about completing tickets. A significant part of project execution is maintaining a shared understanding of the project’s current state.

Everyone involved should be able to answer a few simple questions: where are we, what changed, what is blocked, what happens next, are we still on track, and is there a decision that needs attention?

Communication

For larger projects, I like a short recurring project update. It doesn’t need to include everything that happened during the week. It should focus on the changes that matter.

# Project Update — 4 September

Overall Status: 🟡 At Risk

## Progress

✅ SDK v2 released
✅ First production experiment completed
🔄 Analytics validation in progress

## Next

- Validate experiment metrics
- Start Team A migration
- Publish integration documentation

## Risks

🟡 Analytics validation is 4 days behind schedule.

Impact:
Team A migration may move from Sep 10 → Sep 14.

Mitigation:
Analytics and Experimentation teams are pairing this week.

## Decisions

Decision required:
Should Team B migration begin before analytics validation completes?

Owner: Product Director
Needed by: Sep 8

A good project update should make it easy for stakeholders to understand what changed and where their attention is required, ideally in less than two minutes.

Track risks, assumptions, issues and dependencies

For complex projects, a small RAID log can be very effective:

R — Risks
A — Assumptions
I — Issues
D — Dependencies

For example:

The distinction between a risk and an issue is important. A risk might happen. An issue is already happening. Keeping the two separate makes it much easier to understand whether the project is dealing with potential problems or active ones.

Decisions

Large projects also accumulate decisions, and those decisions quickly lose context if they are only captured in Slack threads or meeting notes.

A simple decision log can help:

## Decision 014

Date:
Decision:
Context:
Options considered:
Why this option:
Trade-offs:
Participants:

This becomes especially useful in long-running technical projects where architecture, product and operational decisions evolve over time. Six weeks later, when someone asks why a particular approach was chosen, the answer should be easy to find.

Using AI during execution

This is probably the phase where AI can drive the biggest productivity gains because project execution produces a constant stream of information: Jira updates, meeting notes, Slack discussions, dashboards, decisions, and status changes.

Instead of manually rebuilding the same picture every week, AI can help compare the current state against the previous one.

Generate this week's project update.

Compare the current information against last week's update.

Identify:

1. Meaningful progress
2. New blockers
3. New or increased risks
4. Milestones that may slip
5. Decisions that are required
6. Dependencies whose status changed

Do not treat completed tickets as meaningful progress unless they affect a milestone.

Highlight uncertainty instead of guessing.

Keep the update concise enough to read in less than 2 minutes.

One of my favourite questions in this context is simply:

What has changed that I should care about?

That is often much more valuable than asking AI to summarise everything.

AI as a project reviewer

It can also be useful to periodically ask AI to review the overall project state rather than only summarising recent activity.

For example:

Review the current project state as an independent senior engineering leader.

Based on the original goals, milestones, risks and current progress:

1. Are we still solving the original problem?
2. Are the success metrics still achievable?
3. Is scope expanding?
4. Which milestone has the highest probability of slipping?
5. Which dependency should receive more attention?
6. What risk are we probably underestimating?
7. Which decision is currently slowing the project down?

Be critical.

Project leads naturally become close to the work, so having another perspective that continuously checks the project against its original goals can be useful.

4. Closing

Closing is probably the phase that engineering teams ignore most often. The project launches, everyone is happy that the work is finished, and almost immediately the organisation moves on to the next problem.

That is understandable, but it means teams often miss the opportunity to answer a much more important question:

Did the project actually achieve what we originally wanted?

The easiest way to answer that is to go back to the project charter and compare the original success metrics with the final results.

If the targets were:

95% of experiments migrated
<10ms assignment latency
All teams able to create experiments
Legacy platform decommissioned

The final result might look like:

98% experiments migrated       ✅
7ms P95 assignment latency     ✅
12/12 teams onboarded          ✅
Legacy platform removed        ✅

That gives us a much better picture than saying the migration is complete because all the Jira tickets were closed.

Run a retrospective

A retrospective should help improve the next project rather than simply documenting what happened in the current one.

I like the Start → Stop → Continue format because it tends to produce more actionable outcomes.

START

Run dependency reviews earlier.

STOP

Starting implementation before technical designs
have been reviewed by dependent teams.

CONTINUE

Weekly asynchronous project updates.

The objective is not to create a perfect retrospective document. The objective is to change how future projects are run.

Demonstrate impact

Project closing also has a leadership and communication component that is easy to underestimate. Teams should be able to explain what they achieved in terms of impact, not only output.

For example:

We built a new experimentation SDK.

is much weaker than:

We migrated 12 teams to the new experimentation platform, reduced experiment setup from two days to thirty minutes, and removed the operational cost of maintaining the legacy platform.

The first describes what was built. The second describes why it mattered.

Closeout report

For significant projects, I would produce a short closeout document.

# Project Closeout

## Executive Summary
What did we achieve?

## Original Goals
What were we trying to accomplish?

## Results

| Metric | Target | Result |
|--------|--------|--------|

## What Worked
What should we repeat?

## What Didn't
What should change?

## Major Decisions
What important decisions shaped the project?

## Lessons Learned
What did we learn?

## Remaining Work
Is anything unfinished?

## Next Steps
What happens after the project?

## Contributors
Who helped make the project successful?

Then the project can genuinely be closed, rather than remaining permanently at 95% complete while everyone has already moved on.

AI should reduce project management overhead, not ownership

There is an obvious temptation with AI: feed it Jira, Slack, documentation and meeting notes, and let it manage everything.

I do not think that is the right objective.

A large part of project management is information processing. Meetings produce notes, notes create decisions, decisions create tasks, tasks appear in Jira, and Jira updates eventually become stakeholder communications.

AI can help enormously with this flow.

Meetings
   ↓
Notes
   ↓
Decisions
   ↓
Tasks
   ↓
Jira
   ↓
Status updates
   ↓
Stakeholder communication

However, another layer of project management involves judgement, prioritisation, negotiation, accountability, and leadership.

AI can tell you that a dependency appears likely to delay a milestone, but it cannot have the difficult conversation with the team that owns that dependency. It can detect that two stakeholders appear to have different definitions of success, but it cannot create alignment between them. It can suggest that a feature should probably be removed from scope, but someone still needs to make that decision and own the consequences.

The project manager’s job therefore does not disappear. Instead, AI creates an opportunity to spend less time collecting and formatting information and more time on the parts of the role that actually require judgement.

My AI project management setup

If I were starting a significant project tomorrow, I would maintain six lightweight documents:

01 — Project Charter
02 — Project Plan
03 — RAID Log
04 — Decision Log
05 — Weekly Updates
06 — Closeout Report

Together, they create the context needed to understand how the project is progressing.

                 Project Charter
                       │
                       ↓
                  Project Plan
                       │
          ┌────────────┴────────────┐
          ↓                         ↓
       RAID Log                Decision Log
          │                         │
          └────────────┬────────────┘
                       ↓
                 Weekly Update
                       │
                       ↓
                Closeout Report

AI can sit across this workflow and help challenge assumptions, identify missing risks, summarise progress, detect changes, prepare stakeholder updates, analyse dependencies, document decisions and prepare retrospectives.

However, the documents should remain the source of truth, not the AI conversation. That distinction matters because project knowledge needs to be durable, reviewable and accessible to the team.

A reusable project prompt

Finally, I would keep one reusable prompt that can be used throughout the project’s lifetime.

You are my project management copilot.

I am managing the following engineering project.

PROJECT CHARTER
[INSERT]

PROJECT PLAN
[INSERT]

CURRENT RAID LOG
[INSERT]

RECENT DECISIONS
[INSERT]

LATEST PROJECT UPDATE
[INSERT]

Your role is to help me manage the project, not manage it for me.

When analysing information:

1. Separate facts from assumptions.
2. Never invent project status.
3. Highlight missing information.
4. Identify risks and dependencies.
5. Flag potential scope creep.
6. Compare progress against project goals and milestones.
7. Prioritise outcomes over completed tasks.
8. Identify decisions that require human ownership.
9. Challenge my assumptions when appropriate.
10. Keep recommendations actionable.

When I provide new project information, explain what changed and whether it affects:
- scope
- milestones
- risks
- dependencies
- decisions
- success metrics

Always optimise for project clarity rather than producing more documentation.

That last sentence is probably the principle I care about most.

Good project management is not about creating more Jira tickets, spreadsheets, meetings or status reports. It is about creating enough structure that everyone understands what we are trying to achieve, how we are getting there, where we are now, and what needs to happen next.

AI can make that process much more efficient, but only if we use it to reduce noise rather than create more.