# 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