Wiki.Quizz.vn

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Project Constraints ======

===== Introduction =====

Projects rarely have unlimited freedom.

Teams cannot simply say:

  "Build everything we want, with unlimited time and unlimited money."

Reality is different.

Every project operates under limitations.

These limitations are called:

> Project Constraints

Project constraints are the boundaries within which a project must operate.

They influence:

  * planning
  * decision-making
  * priorities
  * delivery strategy
  * stakeholder expectations

A project manager constantly balances these constraints.

Without understanding constraints, projects become:

  * late
  * expensive
  * low quality
  * poorly scoped
  * difficult to control

Understanding constraints is therefore a core PMP concept.

-----

===== Why Constraints Exist =====

Organizations have limited resources.

Examples:

  * limited budget
  * limited people
  * limited time
  * technical limitations
  * business pressure

Stakeholders often want:

  * more features
  * faster delivery
  * lower cost
  * higher quality

These goals can conflict.

Project management exists partly to manage these trade-offs.

-----

===== The Triple Constraint =====

The most famous PMP concept is:

> Triple Constraint

Three primary constraints:

  * Scope
  * Time
  * Cost

These form the classic project management triangle.

```text
        Scope
          /\
         /  \
        /    \
       /      \
    Time ---- Cost
```

The idea:

Changing one constraint usually affects the others.

Projects require balance.

-----

===== Constraint 1 — Scope =====

Scope defines:

> What work will be performed and what deliverables will be produced.

Scope answers:

  * What are we building?
  * What features exist?
  * What is included?
  * What is excluded?

Scope provides boundaries.

Without scope:

Projects become uncontrolled.

-----

===== Scope Example =====

Client requests:

"Build customer notification system."

This is unclear.

Scope clarification:

Included:

  * email notifications
  * admin configuration
  * delivery logs

Excluded:

  * SMS
  * WhatsApp
  * voice call integration

Now expectations are clearer.

Scope prevents misunderstanding.

-----

===== Scope Creep =====

One major project risk:

> Scope Creep

This means:

Uncontrolled expansion of project scope without proper adjustment to time or cost.

Example:

Initial agreement:

Email notifications.

Later requests:

  * SMS
  * Telegram
  * AI-generated messages
  * multilingual templates

But:

  * no schedule increase
  * no budget increase

This creates stress and failure risk.

Scope must be controlled.

-----

===== Constraint 2 — Time =====

Time refers to:

> The schedule available to complete project work.

Time includes:

  * deadlines
  * milestones
  * release dates
  * delivery windows

Projects are temporary.

Time pressure is normal.

-----

===== Time Example =====

Scenario:

Retail platform must launch before:

Holiday season.

Deadline:

November 1.

Even if additional improvements are possible—

time constraint limits work.

Team may need to:

  * reduce scope
  * prioritize critical features
  * postpone enhancements

Time influences delivery strategy.

-----

===== Schedule Compression =====

Sometimes management requests:

"Finish faster."

This creates schedule compression.

Two common approaches:

===== Crashing =====

Add resources.

Example:

More developers.

Result:

Higher cost.

-----

===== Fast Tracking =====

Run activities in parallel.

Example:

Begin testing before full development completion.

Result:

Higher coordination risk.

Time reduction often has consequences.

-----

===== Constraint 3 — Cost =====

Cost refers to:

> Budget available for the project.

Costs include:

  * labor
  * infrastructure
  * software licenses
  * vendors
  * cloud services
  * testing environments

Budget limitations affect decisions.

-----

===== Cost Example =====

Scenario:

AWS migration budget:

$40,000

Desired architecture:

  * Multi-region
  * advanced monitoring
  * high redundancy

Budget reality:

Only supports:

  * single-region HA
  * essential monitoring

Cost influences architecture.

This is common in engineering projects.

-----

===== Cost Overrun =====

A common project problem:

> Cost Overrun

Meaning:

Actual spending exceeds budget.

Causes:

  * underestimated work
  * poor planning
  * scope creep
  * delays
  * vendor dependency

Cost control matters.

-----

===== Expanded Constraints =====

Modern PMP often extends beyond the classic triangle.

Sometimes called:

> Six Constraints

These include:

  * Scope
  * Time
  * Cost
  * Quality
  * Resources
  * Risk

Projects are more complex than the original model.

-----

===== Constraint 4 — Quality =====

Quality means:

> Degree to which deliverables meet requirements and expectations.

Quality is not:

"Perfect."

Quality means:

Fit for purpose.

-----

===== Quality Example =====

Example:

Payment gateway integration.

Requirements:

  * secure
  * reliable
  * compliant

If released with:

  * failed transactions
  * weak security
  * instability

Then:

Quality failure.

Even if delivered on time.

Quality matters.

-----

===== Trade-Off With Quality =====

Pressure example:

"Launch next week."

Possible impact:

Reduced testing.

This increases:

  * defect risk
  * outage risk
  * support cost

Faster is not always better.

PM balances delivery and quality.

-----

===== Constraint 5 — Resources =====

Resources include:

  * people
  * skills
  * equipment
  * infrastructure
  * tools

Projects depend on resource availability.

-----

===== Resource Example =====

Scenario:

Critical developer unavailable.

Impact:

  * slower delivery
  * knowledge gaps
  * delayed decisions

Resource constraints affect schedule.

Even strong plans fail without capacity.

-----

===== Constraint 6 — Risk =====

Risk is:

> Uncertain event that may affect project objectives.

Risk may be:

  * technical
  * financial
  * operational
  * organizational

Every project contains risk.

Ignoring risk does not remove it.

-----

===== Risk Example =====

Project depends on:

Third-party API approval.

Risk:

Vendor delay.

Possible mitigation:

  * early integration
  * backup approach
  * schedule buffer

Risk thinking is proactive.

-----

===== Trade-Off Thinking =====

Project management often means:

> Managing trade-offs

Stakeholders may request:

  * faster
  * cheaper
  * more features

These goals conflict.

Example:

Client asks:

"Can we launch one month earlier?"

Possible responses:

Option A:

Reduce scope.

Option B:

Increase budget.

Option C:

Accept higher risk.

No free improvement exists.

Every change has impact.

-----

===== Real-World Software Example =====

Scenario:

EKS deployment project.

Desired system:

  * Multi-AZ
  * Redis HA
  * CI/CD
  * monitoring
  * autoscaling

Constraints:

Time:

2 months.

Cost:

Limited infrastructure budget.

Resources:

Small team.

PM decisions:

Keep:

  * production deployment
  * essential monitoring

Postpone:

  * advanced observability
  * multi-region DR

Why?

Constraints required prioritization.

This is realistic project management.

-----

===== Constraint Interaction =====

Constraints influence each other.

Example:

Increase scope:

Usually increases:

  * time
  * cost
  * risk

Reduce cost:

May reduce:

  * resources
  * quality
  * schedule flexibility

Compress time:

May increase:

  * defects
  * burnout
  * cost

PM work involves understanding these relationships.

-----

===== Common Mistakes =====

===== Mistake 1 — Ignoring Constraints =====

Assuming:

"Everything is possible."

Reality:

Constraints always exist.

Ignoring them creates failure.

-----

===== Mistake 2 — Accepting Unlimited Scope =====

Trying to satisfy every request.

Result:

  * delay
  * burnout
  * unstable delivery

Scope must have boundaries.

-----

===== Mistake 3 — Unrealistic Deadlines =====

Management sometimes sets dates without planning.

Example:

"Deliver in two weeks."

Without:

  * estimation
  * dependency analysis
  * risk review

This is dangerous.

-----

===== Why Constraints Matter in PMP =====

PMP teaches:

Projects are balancing systems.

PM role is not merely:

"Push team harder."

Instead:

Understand reality and optimize decisions.

Constraint management improves:

  * predictability
  * communication
  * trust
  * delivery success

This is a core PMP mindset.

-----

===== Software Engineering Perspective =====

Engineers experience constraints daily.

Examples:

Scope:

Feature requests.

Time:

Release deadlines.

Cost:

Cloud budget.

Quality:

Production reliability.

Resources:

Limited team capacity.

Risk:

Vendor APIs.

Understanding constraints helps engineers:

  * estimate better
  * negotiate realistically
  * prioritize work
  * lead projects effectively

Technical skill alone is insufficient.

Constraint thinking improves leadership.

-----

===== Key Takeaways =====

  * Projects operate under constraints.
  * Triple Constraint includes Scope, Time, and Cost.
  * Modern projects also consider Quality, Resources, and Risk.
  * Constraints interact with one another.
  * Trade-offs are unavoidable.
  * PMs balance competing demands.
  * Successful delivery requires realistic planning.

-----

===== Reflection Questions =====

  * Which constraint most affects my projects today?
  * Have I experienced scope creep?
  * How do deadlines influence quality in my work?
  * Have I ever accepted unrealistic constraints?