Scope, Ethics, and Constraints
Not sure you’re ready?
Take the ~3-minute readiness diagnostic and see where you stand.
Imagine trying to build a bridge across a turbulent river without knowing the strength of your materials, the physical boundaries of your construction site, or the ethical obligations you owe to the town relying on your structure. Project management is exactly this exercise in bounded reality. It is the art of achieving highly specific goals under strict limitations, where every decision cascades through a system of interconnected variables. To succeed, you must understand the physics of your project environment, accurately map the terrain of your scope, and strictly adhere to the professional rules of engagement.
Before a project team lays a single brick or writes a line of code, they must understand the forces acting upon their environment. Project professionals must flawlessly distinguish between four critical forces: constraints, assumptions, risks, and issues.
Constraints: The Laws of Physics
A project constraint is a known limiting factor that restricts the project team's options during execution. Think of constraints as the walls of a room—they dictate the absolute boundaries within which a project team must operate.
The Iron Triangle The traditional Iron Triangle of project management constraints includes project scope, time, and cost. The defining characteristic of the Iron Triangle is its interconnectedness: modifying one project constraint typically forces an impact on at least one other project constraint.
For instance, increasing the scope of a project usually requires an increase in project time or project cost. You cannot simply build a larger bridge without either spending more money on materials or extending the deadline. Modern project management recognizes that this triangle is an oversimplification. Today, the Project Management Institute (PMI) identifies six primary project constraints. The six primary project constraints are scope, schedule, budget, quality, resources, and risks.
Assumptions: The Hypotheses
A project assumption is a factor in the planning process that is considered to be true without requiring immediate proof. If you assume your software developers will be available 40 hours a week, you plan accordingly. However, project assumptions carry an inherent degree of risk because the assumptions might prove to be false. Therefore, project assumptions must be regularly validated throughout the project lifecycle. If left unchecked, unvalidated project assumptions can become project risks.
Risks vs. Issues: Potential vs. Reality
A project risk is an uncertain event or condition that can impact project objectives if the event occurs. It is vital to understand that risk is not inherently bad. While a project risk can have a negative effect on project objectives (e.g., a critical supplier going bankrupt), a project risk can also have a positive effect on project objectives (e.g., a new technology releasing early, accelerating your schedule). All project risks must be logged and tracked in a risk register document.
An issue, on the other hand, is a risk that has crossed the threshold from probability into reality. A project issue is a current condition or situation that has already occurred and is impacting project objectives. When a project risk materializes into a reality, the risk becomes a project issue. Because they require immediate management, project issues must be logged and tracked in an issue log document.
| Concept | Definition | Status | Tracking Document |
|---|---|---|---|
| Constraint | A known limiting factor restricting team options. | Certain / Absolute | Project Management Plan |
| Assumption | A factor considered true without immediate proof. | Unproven | Assumption Log |
| Risk | An uncertain event impacting objectives. | Potential (Future) | Risk Register |
| Issue | A current condition impacting objectives. | Materialized (Current) | Issue Log |
If constraints are the laws of physics, scope is the map of your territory. Defining scope precisely is the only way to know when you have actually finished a project.
Product Scope vs. Project Scope
We must draw a sharp line between the product and the project.
- Product scope refers to the specific features and functions that characterize a final product, service, or result. (e.g., The software will have a login screen, a dashboard, and export functionality).
- Project scope encompasses all the work performed to deliver a product, service, or result with the specified features. (e.g., The coding, the testing, the team meetings, and the deployment processes required to build that software).
The Scope Baseline and the WBS
To manage the work, you must document it. The project scope statement documents the entire scope, including deliverables, requirements, and boundaries. When you are critiquing a project scope statement, the process involves verifying that all project deliverables have measurable acceptance criteria. If a deliverable cannot be objectively measured, it cannot be formally accepted.
A crucial part of defining boundaries is knowing where the map ends. A project exclusion is an explicit statement of what is deliberately not included in the project scope. Documenting project exclusions helps manage stakeholder expectations by preventing assumptions about unstated features.
The definitive, locked-in version of this map is the project scope baseline. The project scope baseline consists of the approved project scope statement, the Work Breakdown Structure (WBS), and the Work Breakdown Structure dictionary. The Work Breakdown Structure is a hierarchical decomposition of the total scope of work to be carried out by the project team. It breaks massive deliverables down into manageable, estimable components.
Monsters on the Map: Scope Creep and Gold Plating
Two behavioral phenomena continually threaten the scope baseline:
- Scope creep is the uncontrolled expansion of product or project scope without corresponding adjustments to time, cost, and resources. Scope creep typically occurs when project changes bypass the formal integrated change control process. It is the slow, deadly accumulation of "just one more tiny feature."
- Gold plating occurs when project team members intentionally deliver more features than the customer explicitly requested. A developer might think, “I know they didn’t ask for dark mode, but I’m going to build it because it looks great!” This is highly dangerous. Gold plating wastes project resources on unapproved features, introducing unnecessary risk and maintenance burdens.
Reaching the Destination: Control and Validation
Throughout execution, we perform scope control, which is the process of monitoring the status of the project scope and managing changes to the scope baseline.
When the work is complete, we enter scope validation. Scope validation is the formalized acceptance of the completed project deliverables by the proper authority. Crucially, the project team does not validate their own work—the project customer or the project sponsor typically performs the formal scope validation process.
Just as a project is governed by constraints and scope, a project manager is governed by professional ethics. The Project Management Institute Code of Ethics and Professional Conduct is built on four core values: responsibility, respect, fairness, and honesty.
Ignorance of the Project Management Institute Code of Ethics and Professional Conduct is not a valid excuse for unethical behavior.
Who Must Comply?
The Code’s reach is broad. It applies to:
- All Project Management Institute members.
- Non-members who hold a Project Management Institute certification.
- Non-members who apply to commence a Project Management Institute certification process.
- Non-members who serve the Project Management Institute in a volunteer capacity.
However, professional ethics exist alongside civil society. Project managers must obey the laws of the country in which the project managers are operating. The Project Management Institute Code of Ethics and Professional Conduct does not supersede local or national laws.
Aspirational vs. Mandatory Standards
The Code divides its rules into two categories:
- Aspirational standards in the Code of Ethics represent the optimal ethical behaviors that project managers strive to exhibit.
- Mandatory standards in the Code of Ethics represent the minimum acceptable ethical behaviors for project managers. Violating a mandatory standard subjects a practitioner to disciplinary procedures before the Project Management Institute Ethics Review Committee.
Let's examine how the four core values dictate behavior in the real world.
1. Responsibility
Responsibility is the duty to take ownership of decisions made, actions taken, and the resulting consequences.
Ethical responsibility starts before the project even begins: a project manager must accept assignments only if the project manager has the appropriate background, experience, skills, and qualifications. Faking your way into a highly technical engineering project is an ethical breach.
During the project, a project manager must protect proprietary and confidential information entrusted to the project manager by clients or employers. Furthermore, if you witness wrongdoing, silence is complicity. Reporting unethical or illegal conduct to the appropriate authorities is a mandatory standard under the value of responsibility.
2. Respect
Respect is the duty to show a high regard for oneself, others, and the resources entrusted to the practitioner.
In a business environment, this means a project manager must explicitly respect the intellectual property rights of others. You cannot steal a competitor's code or pirate software for your team. It also means a project manager must not use the project manager's position or expertise to influence decisions for personal benefit.
When dealing with vendors and stakeholders, negotiating in good faith is an aspirational standard under the ethical value of respect. You strive to reach agreements where all parties understand the terms honestly.
3. Fairness
Fairness is the duty to make decisions and act impartially and objectively. The ethical value of fairness requires practitioners to remain free from competing self-interest, prejudice, and favoritism.
This value is frequently tested by conflicts of interest. A conflict of interest occurs when an individual is in a position to exploit a professional capacity for personal benefit—for example, if you are selecting a software vendor for your company, and one of the bidding vendors is owned by your spouse. In these situations, proactively disclosing any real or potential conflicts of interest to stakeholders is a mandatory standard under the value of fairness. Transparency neutralizes the conflict.
4. Honesty
Honesty is the duty to understand the truth and act in a truthful manner in all communications and conduct.
In project management, truth is usually found in data. Providing accurate and truthful project status reports is a mandatory standard under the value of honesty. If your project is three months behind schedule and heavily over budget, you cannot manipulate the reporting dashboard to show "green" status. Withholding negative project information from a project sponsor violates the mandatory ethical standard of honesty.
Honesty also applies to how you treat your peers. Filing a frivolous ethics complaint against a colleague violates the Project Management Institute Code of Ethics. To protect the integrity of the profession, all formal ethics complaints submitted by a project manager must be fully substantiated by facts.