The Six Core Principles

What a Principle Is

A process tells you what to do when the situation matches a known pattern. A principle tells you what to care about when the situation is messy. Projects create those messy moments constantly: a sponsor asks for speed at the expense of quality, a team is overloaded but afraid to say so, a technically correct deliverable does not solve the business problem, or a stakeholder group resists the change after the project has already spent the money.

PMBOK8 uses six core principles to describe the behaviors and judgments that effective project management depends on. They are not a replacement for planning, scheduling, risk management, or change control. They are the standards you use when the process alone is not enough, and they shape ordinary decisions too: how much documentation is proportionate for this project, whether a stakeholder relationship needs more attention, or when to raise a risk that is not yet a fire. A project manager who knows the mechanics but ignores the principles can still run a project badly.

Principle 1 - Adopt a Holistic View

A project does not live by itself. It sits inside an organization, a strategy, a budget environment, a stakeholder network, and often a portfolio of other projects competing for the same people. A holistic PM looks beyond the task list and asks how the parts affect each other.

In practice, this means watching the connections: a scope change affects schedule, cost, risk, resources, stakeholder expectations, and sometimes the business case. A schedule compression decision may solve a deadline problem while creating a quality problem. A stakeholder who appears minor on the org chart may control access to the operational team that must adopt the final deliverable.

Without it, the PM falls into local optimization. One visible problem gets solved while quieter problems form somewhere else. The project may look controlled in one report column while drifting in the system around it.

Principle 2 - Focus on Value

Projects are funded because someone expects value. That value may be revenue, cost reduction, compliance, customer retention, risk reduction, service improvement, or strategic positioning. The deliverables matter because of the value they are supposed to create.

The PM's job is to keep that value visible. The business case is not a document to read once and forget. It is the reference point for trade-off decisions. When someone asks for extra scope, the question is not only "Can we do it?" The sharper question is "Does this help the project create the value it was approved to create?"

Skip this and you get projects that are busy but not useful. The team delivers the agreed work, and the organization still does not get the outcome it needed.

Principle 3 - Embed Quality

Quality is not something you inspect into the project at the end. It has to be built into the work. That starts with clear acceptance criteria (the agreed-upon standards a deliverable must meet before it is formally accepted), continues through reviews and checkpoints, and ends with deliverables that can be accepted without late arguments over what "done" was supposed to mean.

Embedding quality does not mean making every deliverable perfect. It means defining the right standard early and building the work process around that standard. For a software project, that may mean test criteria before development begins. For a relocation project, it may mean inspection gates for lease review, fit-out, IT readiness, and old-office handback. For a training project, it may mean measuring whether behavior changed, not only whether people attended.

The cost of skipping it is real. Defects and misunderstandings found late cost more than problems caught while the work is still being shaped.

Principle 4 - Lead Accountably

Project leadership is not just encouragement and coordination. It is accountability for decisions, commitments, transparency, and follow-through. The PM may not own the business outcome or directly manage every team member, but the PM is still responsible for creating enough structure that the project can be managed honestly.

Accountable leadership shows up in ordinary actions: raising bad news early, documenting decisions, making trade-offs visible, protecting the team from informal scope pressure, and telling the sponsor when the current plan no longer matches reality. It also means not hiding behind process. If the report says green but the PM knows the team is one dependency away from trouble, accountable leadership names the risk.

The failure mode here is avoidance. The PM waits too long, softens the message too much, or lets ambiguity sit because clarity would require a difficult conversation.

Principle 5 - Integrate Sustainability

Sustainability in project management is broader than environmental impact, though that can be part of it. It means considering whether the project outcome can be maintained, operated, adopted, and justified after the project team leaves. A deliverable that works for one week but creates an operational burden for three years is not a clean success.

This principle asks the PM to think past handoff. Who will own the result? What cost, staffing, support, training, compliance, or maintenance does it create? Are there environmental, social, ethical, or long-term business effects that should influence the project approach? These questions belong early enough to shape scope and planning, not only at closure.

For the Meridian relocation, sustainability questions include whether the Westfield office genuinely reduces operational friction long term, whether facilities and IT can support the space after the project team is gone, and whether the lease investment holds value across the full lease term.

Miss it, and the outcome is brittle. The project closes, the report says success, and the receiving organization quietly struggles with what was handed over.

Principle 6 - Build Empowered Teams

Projects are delivered by people, not by plans. An empowered team has enough clarity, authority, trust, information, and support to do the work without waiting for the PM to make every small decision. This does not remove accountability. It places decisions closer to the people with the best information.

The PM builds that environment through role clarity, working agreements, psychological safety (an environment where team members can speak up, raise concerns, and admit mistakes without fear of punishment), visible priorities, conflict management, and realistic resource planning. Empowerment is not the same as abandoning the team. The PM still sets direction, removes blockers, escalates when needed, and protects the team from noise.

Without it, the team becomes dependent. Members wait for permission, problems surface late, and the PM becomes the bottleneck for decisions the team could have made faster.

Using the Principles in Practice

The six principles are not a checklist to complete during kickoff. They are questions to carry into decisions:

• Am I seeing the whole system, or only the part of the project in front of me?
• Does this decision protect the value the project was approved to create?
• Are we building quality into the work, or hoping inspection will catch problems later?
• Am I leading accountably, especially where the news is uncomfortable?
• Will the outcome still make sense after the project team leaves?
• Does the team have the clarity and authority needed to do the work well?

Those questions will not replace judgment. They improve it. They force the PM to look beyond the immediate pressure and make decisions that hold up after the meeting ends.

What's Next

The next chapter covers the seven performance domains: the broad categories of PM work and outcomes that PMBOK8 says every project manager is accountable for. Where the principles describe what to care about, the domains describe what must be managed.

Reflect

• Which of the six principles do you already apply naturally? Which one would require the most deliberate attention from you?
• Think about a project that delivered the agreed work but did not create the expected value. Which principle was missing?
• Where have you seen quality treated as a final inspection problem instead of something built into the work?
• What would an empowered team need from you as PM that a dependent team would not ask for?