# The Triple Constraint

<figure><img src="https://4246541480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MfSJs1xxvnSku39x_Mq%2Fuploads%2FqjZ6kv8K1B11HDLpBmTl%2Fimage.png?alt=media&#x26;token=4a1d3cec-70c8-43d6-9800-a132331e827a" alt="" width="375"><figcaption><p>The Triple Constaint of Project Management</p></figcaption></figure>

## The What

The 3 factors in project management. Any adjustment to one of them affects the other two. We must carefully navigate these constraints to achieve project success. To put it super simple

* Cost: The total number of engineers
* Scope: A list of features&#x20;
* Time: Deadline

## The How

Does that mean a project manager can play with all 3 factors? The answer is a clear no. Most of the time, there is at least one factor you can't change, the trade-off is mostly between the rest 2 feasible constraints&#x20;

### In an Agile Team

Imagine a high-performing cross-functional team where members know each other well, fostering excellent communication. What does their triangle look like?

#### <mark style="background-color:red;">Cost</mark> :x:

Normally fixed, limited by headcount, and budget. Compete with other priorities. Importantly, increasing developers doesn’t necessarily boost productivity and adding a new member to a high-performing team can slow them down.

#### Scope & Time :white\_check\_mark:

The scope of the project is negotiable. At the discovery stage, we just have a list of features we would like to deliver, but some are must-haves and the rest are nice-to-haves. So in an agile team, we normally prioritise features and put them in sequence. For example

* MVP: Feature A, B, C
* Fast Follow: Feature X & Y, and optimising feature A
* Settle Down: Code clean up or address some technical debt

#### In a Project Team

Imagine a consultant company with a large talent pool. They are able to form a team and get stuff done quickly. What does their triangle look like?

#### <mark style="background-color:red;">Scope</mark> :x:

Negotiable, but once agreed, it becomes the agreement between the two parties.&#x20;

#### Cost & Time :white\_check\_mark:

Based on estimation. It is very challenging. People write books to express how hard it can be.

## :scroll: Tips

Some quotes from The Mythical Man-Month by Fred Brooks in 1975.&#x20;

PS: Man=Cost and Month=Time

> Adding manpower to a late software project, makes it later

> For the human makers of things, the incompletenesses and inconsistencies of our ideas become clear only during implementation

> Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them

> How does a project get to be a year late? . . . . One day at a time


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://jamiewen00.gitbook.io/tech-lead-handbook/project/the-triple-constraint.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
