Every project methodology on the market hands you two very different kinds of advice, and most of us never stop to separate them. There are principles, the handful of rules that explain why we do things a certain way, and there are processes, the long checklists that spell out what to do, step by step. Confuse the two and you end up dutifully running a process nobody remembers the reason for. That gap is exactly where the Nearly Universal Principles of Projects (NUPP) earn their keep, so let me start there before I get to them.
Principles and processes are not the same thing
A principle is a general guideline. It sets the foundation for how a project gets planned and executed, it reflects best practices and industry standards, and it tends to be broad rather than tied to any single piece of work. That breadth is the point: a good principle survives the move from a construction site to a software sprint to a clinical trial without needing a rewrite.
A few familiar examples make the abstraction concrete. Define the project scope, objectives, and deliverables, which means drawing the boundaries of what is and is not included, naming the specific goals the work aims to hit, and stating the outputs it will actually produce. Identify and prioritize your stakeholders, which means finding every individual or organization affected by the project or invested in its outcome, understanding their needs and expectations, and ranking them by their real level of influence rather than by who shouts loudest. Plan for risk and keep contingency plans ready, where the contingency is the alternate course of action you can trigger the moment something goes wrong. And pick tools and techniques (project management software, Gantt charts, earned value analysis) that genuinely fit the job of execution and control, instead of adopting them because a certification slide said you should.
A process is the concrete action you take to satisfy those objectives. Processes usually live inside a methodology, the way the Project Management Institute's PMBOK Guide codifies them, and they get tailored to the specific project in front of you. They are the moving parts, and there are a lot of them. Developing a project schedule means laying out the specific tasks and milestones and fixing a timeline against them. Assembling a team and assigning roles means choosing the people with the right skills and then making each person's responsibilities unambiguous, so the division of labour is clear and nobody assumes someone else has it covered. Establishing a communication plan means deciding what information gets shared, in what form, through which channel, and who is accountable for sending it. Acquiring and allocating resources covers the money, people, equipment, and materials, and the quieter discipline of deploying them where they earn the most. Running quality assurance means verifying deliverables against defined standards through inspections, testing, and reviews scattered across the life of the project, not bolted on at the end. Monitoring and controlling change means having a real procedure so that every shift in scope, schedule, or budget is documented, evaluated, and approved rather than waved through. And closing the project means an honest review of its successes and challenges, a post-project retrospective or a formal audit that turns this project's pain into next project's head start.
Here is the asymmetry that matters: principles are close to universal, while processes multiply. A given implementation often carries far more processes than it needs, and the unused ones quietly become dead weight, busywork performed out of habit. Principles travel; processes pile up. When in doubt, I trust the principle and prune the process.
What the major methodologies actually stand on
Strip each of the big frameworks down to its principles and you can see the family resemblance. They are describing the same underlying truths in different dialects, which is the first hint that something more universal sits underneath all of them.
The PMBOK Guide rests on twelve principles:
| # | Principle | What it asks of you |
|---|---|---|
| 1 | Scope, objectives, deliverables | Draw the boundaries of the project, name its goals, and define the outputs it will produce |
| 2 | Identify and prioritize stakeholders | Find everyone affected by or invested in the project and rank them by influence and impact |
| 3 | Schedule and budget | Lay out the tasks and milestones, and allocate the money to reach them |
| 4 | Team and responsibilities | Staff the work with the right skills and make each person's role unambiguous |
| 5 | Risk management and contingencies | Spot the risks early and prepare alternate courses of action |
| 6 | Communication plan | Decide what gets shared, how, and who is accountable for sharing it |
| 7 | Tools and techniques | Use the right instruments to manage execution and control |
| 8 | Monitor and control work | Track progress against schedule, budget, and pre-defined metrics |
| 9 | Manage and acquire resources | Secure the money, people, equipment, and materials, and deploy them well |
| 10 | Quality assurance | Verify deliverables against quality standards through inspection, testing, and review |
| 11 | Control change | Document, evaluate, and approve every change to scope, schedule, or budget |
| 12 | Close and review | Capture lessons learned in a post-project review or formal audit |
PRINCE2 distills it to seven, and notice how much more opinionated they are. Where PMBOK enumerates activities, PRINCE2 states beliefs about how a project should behave:
| # | Principle | The idea |
|---|---|---|
| 1 | Continued business justification | The project must stay worth doing across its whole lifecycle, not just on the day it was approved |
| 2 | Learn from experience | Review the past deliberately and feed it forward into the current work |
| 3 | Defined roles and responsibilities | Everyone knows what is expected of them |
| 4 | Manage by stages | Break the work into stages with their own objectives and deliverables |
| 5 | Manage by exception | Plan for exceptions and escalate only the deviations that breach agreed tolerances |
| 6 | Focus on products | Aim at delivering specific, tangible products the organization needs |
| 7 | Tailor to the environment | Adapt the method to the project, not the project to the method |
The Agile Manifesto lists twelve principles, and they read less like a checklist and more like a temperament: satisfy the customer through early and continuous delivery of valuable software; welcome changing requirements even late in development, because change is a competitive advantage rather than a failure of planning; ship working software frequently, from a couple of weeks to a couple of months, favouring the shorter timescale; have business people and developers work together daily throughout the project; build projects around motivated individuals, give them the environment and support they need, and then trust them to get the job done; treat face-to-face conversation as the most efficient and effective way to convey information within a team; measure progress primarily by working software; promote sustainable development at a pace sponsors, developers, and users can hold indefinitely; pay continuous attention to technical excellence and good design, because that is what keeps a system agile; pursue simplicity, defined sharply as the art of maximizing the amount of work not done; trust that the best architectures, requirements, and designs emerge from self-organizing teams rather than from a plan handed down; and at regular intervals, have the team reflect on how to become more effective and then tune its behaviour accordingly.
Lay the three side by side and the overlap is impossible to miss. PMBOK's "control change" and Agile's "welcome changing requirements" are the same animal seen from opposite ends of the risk tolerance scale. PRINCE2's "continued business justification" and PMBOK's "close and review" are both asking whether the work still deserves to exist. That convergence is the whole argument for looking underneath.
The six that show up everywhere
Now to NUPP itself. Where the others enumerate, NUPP compresses, down to six principles meant to hold no matter which methodology you reach for. Each one is deliberately phrased to fight a specific human reflex that sabotages projects:
- Prefer results and the truth to affiliations. We are wired to belong to groups, and that instinct often hardens into strong affiliations that cost us. We lose more than we gain by them, because the moment our identity is fused to a camp, a tool, or a vendor, we defend the camp instead of chasing the result. Stop tying your preferences to a particular tribe and you become a more professional, more effective expert, free to borrow whatever actually works.
- Preserve and optimize energy and resources. What the project has is finite, and so is the mental energy you can spend making good decisions. Decision fatigue is real, and a manager who burns their attention on trivia has none left for the calls that matter. Guard and optimize that resource for yourself and the project, and help your teammates do the same.
- Always be proactive. Reactivity is the default setting. It can spare us energy on unimportant matters, and it can even rescue us in areas where we are genuinely out of our depth and better off waiting for events to clarify. Projects are neither of those situations. Here the costs of waiting compound, and proactivity simply wins.
- Remember that a chain is only as strong as its weakest link. A project has many domains and they all interact. Lavishing attention on one that looks important, time being the usual favourite, does nothing if the others are starved, because the neglected domain becomes the link that snaps. You need a holistic view in which scope, cost, quality, risk, and people all get adequate attention rather than the one you happen to enjoy managing.
- Don't do anything without a clear purpose. Before acting, imagine two parallel worlds identical except for the thing you are about to do. How different are they? Is the gap worth the effort? If you are only acting because everyone else does, or because someone insists it matters, the benefit may not exist in your case at all. And even when it does exist, it can slip away, because if you never held the purpose in mind, your way of doing the thing may not be the way that realizes the benefit.
- Use repeatable elements. An ad hoc approach burns energy and resources and constantly runs the risk of missing something necessary. The cleanest way to simplify the work is to lean on repeatable elements, and better still to arrange them in repeatable cycles, so the team stops reinventing the same scaffolding on every project and starts improving it instead.
The NUPP website puts the intent plainly:
NUPP is a collection of nearly universal principles of projects: those we'd do well to follow in all projects, regardless of the methodologies and approaches that we use, to maximize our success. Each of the available resources and methods for running projects relies on some of these NUPs (nearly universal principles).
nupp.guide
Two caveats are worth holding onto. First, any given method usually relies on only some of the principles, never the full set, so practitioners do better to keep all six in view rather than the subset their framework happens to emphasize. Second, the underlying principles are rarely spelled out clearly in the resources themselves, and most practitioners get so buried in practical detail that they forget the principles entirely and start doing things that quietly contradict them.
NUPP is built to sit alongside, not against, the major methods, systems, resources, and frameworks: PRINCE2, the PMBOK Guide, P3.express, PM², DSDM, XP, and Scrum. It may clash with certain interpretations of those systems, and that is precisely the friction NUPP wants to create, nudging practitioners to reconsider how they have been reading their own method rather than abandon it.
Six principles in the wild: a medical device
Let me make this concrete with a project I actually led. Years ago I ran a team building a new portable medical device that uses impedance cardiography to measure cardiac output non-invasively. The bar was high: the device had to clear a battery of regulatory and performance tests, including 95% accuracy in cardiac output measurements against the leading devices on the market. We had 36 months to be ready for regulatory submission, with a pilot production run six months after approval. Looking back, I was applying the NUPP principles before NUPP was ever formalized, and the project framed them slightly differently from the six above, in this sequence.
NUP1: Success is defined by the delivery of customer value. We ran extensive consultations with cardiologists and hospital technicians to understand their real frustrations with the devices they already used, not the frustrations we assumed they had. That feedback drove design changes that improved usability and data accuracy, and we validated each one through pilot testing in clinical settings, so the final product genuinely resonated with the people meant to use it rather than with the engineers who built it.
NUP2: Planning is indispensable. Given the complexity, I put a thorough plan in place: detailed timelines, resource allocations, and milestone goals. Every phase, from concept and prototyping through clinical trials to regulatory submission, was planned out, and regular milestone reviews let us measure progress against the plan and adjust in time. That discipline kept us inside our timelines and budgets while still leaving room to absorb new insights and shifts in the regulatory landscape, which in a regulated medical market move whether you are ready or not.
NUP3: Proactive project management is essential. Anticipating both technological and regulatory hurdles, we stood up a risk management framework at the very start. That meant engaging regulators early to pin down compliance requirements before the design was frozen, and running frequent technology reviews to confirm the design met its technical specs as it evolved. Catching those issues early spared us the major delays and expensive last-minute fixes that sink so many hardware projects in their final stretch.
NUP4: Projects are uncertain; stuff happens. Even with careful planning, a key supplier retired their product from the market with little warning. Because we had already maintained a list of alternative suppliers, we pivoted quickly to a new one with no real damage to the timeline. The project's flexible framework is what made that fast adaptation possible. The uncertainty was not avoidable, but its consequences were.
NUP5: Change is normal and should be managed. Midway through, new scientific research suggested we could improve measurement accuracy with a small change to sensor placement. We did not just bolt it on. We ran it through a structured change control process that weighed the impact on scope, timeline, and budget. After testing confirmed the gain, we implemented it, and it meaningfully improved performance with minimal hit to the schedule, which is exactly what a change process is supposed to buy you.
NUP6: The project organization should align with project needs. As the work progressed, it became clear we needed deeper expertise in digital signal processing to sharpen the device's data analysis. The steering committee restructured the team to bring in a specialist exactly when that skill was required, instead of forcing the existing engineers to fake competence in an unfamiliar field. That organizational adjustment proved decisive for the hardest technical problems and for keeping our momentum toward the submission date.
For all their apparent simplicity, the Nearly Universal Principles of Projects are powerful precisely because they are simple. They give you a stable spine for managing work across wildly different industries and challenges: anticipating problems before they bite, aligning resources deliberately rather than by reflex, and adapting when reality refuses to cooperate with the plan.
Why I keep coming back to them
The NUPP principles are universal and transversal. They hold inside the formal, well-known methodologies (PRINCE2, PMBOK, Scrum, Agile) just as much as in a scrappy one-person project run out of a notebook. Whatever method or set of tools you use, following these principles is what tilts the odds toward success, and it helps to remember that every methodology you currently rely on is built, knowingly or not, on this same body of principles. They are not a competitor to your framework. They are the bedrock it was poured onto.
NUPP is open and free, published under a Creative Commons license at https://nupp.guide/, which is the kind of detail that tells you something about its intent. Methodologies go in and out of fashion. The reasons behind them mostly don't, and that is the part worth memorizing.
(sources: https://www.pmi.org/, https://www.prince2.com/, https://agilemanifesto.org/, https://nupp.guide/) PRINCE2 is a registered trademark of AXELOS Limited. All rights reserved. PMI, PMP, and PMBOK are registered marks of The Project Management Institute, Inc.