Duration: 30–40 minutes

## Definition

Build realistic estimates and distinguish estimates, targets, and commitments.

This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.

## Simple Mental Model

The goal is not to add project-management bureaucracy. The goal is to make the project easier to understand, predict, and manage.

## How It Works

We will examine this concept through four levels:

1. What the concept means.
2. How a project owner should use it.
3. How you should review or challenge it as the manager.
4. How it should eventually appear in your project-management system.

## Example

The exercises for this lesson should use real projects from your environment such as Umami, Mogador, QA automation, data governance, website/Product initiatives, or projects dependent on DevOps and Security.

The objective is to move from theory to a repeatable management practice.

## How It Fits Into the Bigger Picture

The course builds progressively:

- Project vs operations establishes what kind of work we are managing.
- Outcomes and Definition of Done establish what success means.
- Scope establishes the project's boundaries.
- Milestones establish meaningful progress.
- Dependencies, estimation, prioritization, capacity, risks, and health make delivery more predictable.
- Status reporting, meetings, ownership, and portfolio management make the system scalable.
- Closing and the final PM system turn the concepts into an operating method.

## My Company / Real-World Context

Your team works across departmental projects, Product work, operational incidents, tickets, data, QA, SEO/WCAG, and dependencies on IT teams such as DevOps and Security.

The lesson should therefore be applied to an environment where:

- Project owners are usually members of your own team rather than dedicated PMs.
- Operational work regularly interrupts project work.
- Product and IT are important cross-functional partners.
- You need portfolio-level visibility without personally maintaining every task.
- Project owners should increasingly draft and maintain their own project plans while you validate, challenge, prioritize, and escalate.

## CTO Perspective

The leadership objective is to move progressively from personally coordinating work toward building a management system that produces reliable outcomes.

The expected progression is:

```text
Contributor → manages tasks
Project Owner → drives milestones and delivery
Manager → manages projects, priorities, risks and escalation
Technology Leader → manages portfolio, capacity, outcomes and organizational trade-offs
```

### Questions to Ask

- What information do I need to make a management decision?
- What should the project owner be responsible for maintaining?
- What requires my intervention?
- What can be standardized across every project?
- Is the process helping delivery, or merely creating administration?

## Meeting Scenario

**Situation:**

A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome.

**Possible response:**

> Let's bring this back to the project plan. Show me where we are against the next meaningful checkpoint, what is at risk, and what decision or help you need from me.

## Key Takeaways

- The purpose of project management is predictable delivery, not documentation for its own sake.
- Project owners should own increasingly more of the planning and maintenance.
- Your role is to challenge assumptions, establish priorities, remove/escalate blockers, and manage the portfolio.
- Every concept learned should eventually contribute to one lightweight common project template.
- The final system should make exceptions and problems visible without requiring you to inspect every task.

## Related Concepts

- [[Projects vs Operations]]
- [[Project Outcome]]
- [[Definition of Done]]
- [[Scope]]
- [[Milestone]]
- [[Dependencies]]
- [[Capacity]]
- [[Risk]]
- [[Project Health]]
- [[Portfolio Management]]