What Is Project Management? A Plain-English Guide for Beginners

A project is temporary work with an agreed result, and managing it means planning, organizing and steering that work to the result within agreed limits of time and money. That plain-English answer to what is project management is ours; the Project Management Institute (PMI), a US-based professional body, defines it as applying knowledge, skills, tools and techniques to project activities to meet or exceed the intended value.¹

The case for the discipline starts with how often plans fail to hold. In a 2002 study of 258 transport infrastructure projects in 20 countries, Bent Flyvbjerg and colleagues found costs underestimated in almost 9 out of 10, with actual costs 28 percent above estimates on average.² Most of project management is a set of habits for making that gap smaller and seeing it sooner.

Four standards bodies on what is project management

PMI, the International Organization for Standardization (ISO), AXELOS, then owner of the PRINCE2 method, and the UK’s Association for Project Management (APM) all describe a project as temporary. Their definitions of managing one differ in emphasis: PMI stresses value, ISO objectives, PRINCE2 a business case and APM acceptance criteria.

The differences are about emphasis. PRINCE2’s definition puts the business case, the reason for spending the money, inside the definition itself.⁴ PMI rewrote both of its definitions around value in version 5.0 of its lexicon, dated January 2026.¹ Its explainer page still gives the older ending, “to meet project requirements”.⁶ ISO’s definition, published in 2020, leaves out the word “unique” and talks only about objectives.³ That omission matters for estimating, as the research on uniqueness further down suggests.

PMI’s own reference book changed recently. Its PMBOK Guide reached an eighth edition in November 2025. PMI says the new edition keeps the seventh edition’s foundation of principles and performance domains but simplifies it to six core principles and seven performance domains.⁷

Projects end; operations keep going

Time separates a project from ordinary work. ISO 21502 splits an organization’s work into two kinds: projects, which are temporary and add or protect value or capability, and operations, which run through ongoing activities such as delivering repeatable products and services.³ Payroll every month is operations. Moving payroll to a new system is a project.

APM draws the same line for management itself: project management has a final deliverable and a finite timespan, while general management is an ongoing process.⁵ The two meet at the handover. ISO’s standard asks teams to consider the transition to operations and customers when tailoring their approach, and it defines a project’s outcome as the change that results from using its output.³

1. Operations: ongoing, repeatable work, such as running payroll every month
2. A project: temporary work with a start and a finish, such as moving payroll to a new system
3. The handover: the project’s output goes into operations, where using it brings about the intended change

Two neighbouring terms come up quickly. In PMI’s lexicon, a program is a set of related projects managed together to obtain benefits not available from managing them one by one, and a portfolio is a collection of projects, programs and operations managed as a group to achieve strategic objectives.¹ A single website redesign is a project; the company’s whole digital overhaul might be a program; everything the company chooses to fund is its portfolio.

The work itself, from a reason to start to a controlled close

Project management covers the whole life of a project, not only the schedule. APM’s list of core components includes defining why the project is needed, capturing requirements, estimating resources and timescales, preparing a business case, securing funding, leading the team, managing risks, issues and changes, monitoring progress, managing the budget, communicating with stakeholders and closing the project in a controlled way.⁵

ISO’s standard compresses the same work into a sequence: to direct, initiate, plan, monitor, control and close the project, while managing its resources and motivating the people involved.³ The stages below follow that sequence.

1. 1Startagree the reason and the objectives
2. 2Planscope, schedule, budget, risks
3. 3Deliver and monitorcompare progress with the plan
4. 4Closehand over the output

The targets vary by method. APM calls time, cost and quality the building blocks of every project.⁵ PRINCE2’s 2017 glossary names six performance targets: time, cost, quality, scope, benefits and risk.⁴ The official PRINCE2 7 training guide lists seven aspects of performance, adding sustainability.⁸ Either way, the manager balances several limits at once. Our own rule of thumb, not a finding from these sources: when one limit moves, such as a deadline brought forward, check what the change does to the others.

People are part of the definition, not an extra. PRINCE2 includes motivating those involved in its definition, and ISO lists it alongside planning and control.⁴³ Much of the day-to-day work is leading a team, which is why research on what makes a team effective applies to project teams too.

Why projects need managing: estimates run over

Large projects tend to cost more than planned, and the pattern shows up across project types and decades. The strongest single piece of evidence here is Flyvbjerg, Holm and Buhl’s 2002 study in the Journal of the American Planning Association, which compared the cost estimate at the decision to build with the final cost.²

The study

Moderate evidence

Estimated against actual cost in 258 transport projects

After four years of data collection, the researchers had estimated and actual construction costs for bridges, tunnels, roads and rail lines worth about 90 billion US dollars in 1995 prices. Actual costs were on average 45 percent above estimates for rail, 34 percent for bridges and tunnels and 20 percent for roads, and underestimation had not decreased over the 70 years the sample covered.²

The finding describes large public works, and the sample was chosen by which projects had data, so it cannot say how a typical office project behaves. The authors describe their results as most likely conservative and conclude that deliberate underestimation by promoters, not honest error, best explains the pattern.² That explanation is contested: a 2018 critique by Peter Love and Dominic Ahiaga-Dagbui calls the error-or-lie framing a false dichotomy.⁹

IT projects show a different shape of risk. In a sample of 1,471 IT projects, mostly US-based and run by public agencies, Flyvbjerg and Alexander Budzier found an average cost overrun of 27 percent, but one project in six overran by 200 percent on average, with a schedule overrun of almost 70 percent.¹⁰ Their 2011 Harvard Business Review article is not peer-reviewed, and its main point is that averages hide the rare disasters that do the real damage.

Individuals show the same optimism with their own work. In a 1994 study by Roger Buehler, Dale Griffin and Michael Ross, only about 30 percent of 37 psychology students writing honors theses finished by the date they had predicted, an example of what psychologists call the planning fallacy.¹¹ The practical fix, budgeting time from your track record, works the same way for a project plan: look at how long similar work really took before you commit to a date.

A hypothetical example shows the difference. Say your team is asked to move a 40-person office and the first plan says six weeks. If your last three moves took 8, 9 and 11 weeks, a date built from those, around 9 or 10 weeks, is more honest than the six-week plan, and the gap is worth raising with the sponsor before the date is announced rather than after it slips.

How often do projects go wrong? Handle the famous numbers carefully

Failure statistics about projects are less solid than their popularity suggests. The best-known, the Standish Group’s CHAOS report, said in 1994 that 16 percent of software projects succeeded, 53 percent were challenged and 31 percent failed, according to a 2010 analysis in IEEE Software by Laurenz Eveleens and Chris Verhoef.¹²

The CHAOS reports are industry research that, unlike comparable academic surveys, were not subject to scientific review, and their method has drawn sustained criticism.¹³ Robert Glass reported in 2006 that researchers who asked Standish about its data had been rebuffed, and that the 1994 report described asking IT executives to share failure stories, which, if that was the basis, would bias the results toward failure.¹⁴ Eveleens and Verhoef found that the Standish definitions measure only how accurate the original estimates of cost, time and features were, and called the resulting figures meaningless.¹²

Myth

Most projects fail, and software projects overrun their budgets by 189% on average.

Fact

Both claims trace largely to the Standish Group's 1994 CHAOS survey. Three peer-reviewed surveys of US and Canadian software work from 1984 to 1992 found average cost overruns of about 30%, not the 189% the CHAOS report is often quoted as showing.

The overrun figure fares no better. Magne Jørgensen and Kjetil Moløkken-Østvold found in 2006 that the 1994 report’s 189 percent average cost overrun, for projects it classed as challenged, was probably much too high: the other surveys they found from that period suggested about 30 percent.¹³

Industry research from PMI is more transparent about its sample but has limits of its own. PMI’s 2026 Pulse of the Profession surveyed 2,023 project professionals and 511 senior leaders in 35 countries, and reported that about a third of complex projects, 31 percent, failed to achieve the full scope of their originally intended benefits.¹⁵ Those are self-reported judgments from PMI’s own community, not measured outcomes, and PMI, which certifies project managers, is not a neutral party.

What counts as failure is itself shifting. The CHAOS definitions judged a project only against its first estimates of cost, time and features.¹² PMI’s recent research instead defines a successful project as one that delivers value worth the effort and expense, so under that definition a late project that still pays off could count as a success.¹⁵

Projects feel unique, but most have close cousins

ISO 21502 says each project is unique, although many projects have similar features.³ That softer wording may be the more useful one for estimating, because a 2024 working paper linked rating an IT project as more unique to larger cost overruns.¹⁶ APM’s definition calls a project unique without the softening, and PMI’s 2026 lexicon places every project in “a unique context”.⁵¹

A 2024 working paper by Flyvbjerg and three co-authors asked the leaders of 219 IT projects how unique their project was on a 10-point scale. In the 167 projects with cost data, each extra point was linked to a cost overrun about 5 percentage points higher, and their model put truly one-of-a-kind projects about 45 points above projects rated not unique at all.¹⁶ The paper is not peer-reviewed, the link is correlational, and the authors expect their sample of better-organized firms to look better than average.

The lesson for a beginner is practical. A project that feels new usually has cousins: someone has migrated a system, run an office move or launched a product before. Flyvbjerg and Budzier recommend forecasting from the outcomes of similar past projects, including those of other organizations, known as reference class forecasting, instead of building estimates only from the inside.¹⁰ The method is not settled science: a 2025 review in Production Planning and Control says questions remain about its validity, applicability and limits.¹⁷ The 2024 working paper adds premortems and noise audits to the same toolkit for taking this outside view, though it proposes them rather than testing them in its sample.¹⁶

Predictive, adaptive or hybrid: three ways to run a project

PMI describes three broad approaches, chosen by how stable the requirements are. A predictive approach plans in detail up front and finishes each phase before the next begins, which suits well-defined work. An adaptive approach works in iterations and expects requirements to change. A hybrid approach mixes the two.⁶

PMI’s lexicon makes the difference concrete. In a predictive approach, scope, time and cost are determined in the early phases; a hybrid approach is useful when the requirements carry uncertainty or risk.¹ Refitting a warehouse to a signed-off design suits the first. Building a customer app whose features will change after users try it suits an adaptive or hybrid plan.

The best-known adaptive label, agile, comes from software: PMI’s lexicon defines it as a mindset of values and principles set out in the Manifesto for Agile Software Development.¹ That 2001 manifesto, written by 17 software practitioners, valued responding to change over following a plan, while granting that following a plan still has value.¹⁸ ISO 21502 applies to any delivery approach, including predictive, iterative, adaptive and agile ones, so a formal standard and an agile team are not in conflict.³

The bottom line

Every major definition treats a project as temporary work aimed at an agreed result, and managing it as keeping that work within agreed limits. The hard part is estimation: large projects have run over their budgets for decades, and in one 2024 working paper, IT projects their leaders rated as one of a kind had bigger cost overruns. Start any project by writing down its objective and its limits, and set dates from what similar work really took.