Getting Projects Over the Line

Most projects do not fail in a dramatic way. They drift. The deadline moves by a week, then by a month. A few extra features join along the way. The people who asked for the project stop being sure what they asked for. When it finally ends, nobody can say whether it succeeded, because nobody wrote down what success meant.

Project management is the work of preventing that drift. This guide explains what it involves, the handful of decisions that matter most, and where to go deeper on each.

What makes something a project

Routine work repeats: paying invoices, answering support emails, publishing the weekly newsletter. A project has a start and an end and produces something new or changes something: moving the newsletter to a new platform, setting up a help center, choosing a new payroll system.

Because a project is new, it carries uncertainty. You cannot know everything at the start, and some of what you assume will turn out to be wrong. Project management is largely about reducing that uncertainty step by step and deciding well when surprises arrive.

Why it matters

Projects go wrong far more often than most people expect. Bent Flyvbjerg, who has built a database of more than 16,000 projects across 136 countries, found that 91.5% went over budget, over schedule or both, and that fewer than 1% were delivered on time, on budget and with the benefits promised (strategy+business). Those are mostly large projects, but the patterns behind them show up in small ones too: optimistic estimates, unclear goals and scope that keeps growing.

Five things that decide most projects

A clear definition of success. Before planning anything, agree on what the project must achieve and how you will know. “Launch the new help center” is an output. “Cut support tickets on billing questions by a third within three months” is a result you can check. Write it down and get the sponsor to agree.

Firm edges. Every project needs a list of what it will deliver and, just as important, what it will not. Most overruns start with small additions that each seemed reasonable. We cover this in Deciding What the Project Will Not Do.

A plan built on honest estimates. People consistently underestimate how long their own work will take, even when they know they have done so before. A useful plan breaks the work into pieces, estimates each one realistically and keeps a buffer. See Plans That Survive Contact With Reality.

The right approach for the work. Some projects suit a plan made up front and followed in sequence. Others suit short cycles where the plan changes as you learn. Most real projects mix the two. Agile, Waterfall and What Most Teams Actually Do explains how to choose.

People who know what is happening. Projects fail as often from silence as from bad plans. A sponsor who hears about a problem in week two can help; one who hears in week ten usually cannot. Short, regular updates with the same structure each time (what is done, what is next, what is at risk) prevent most surprises.

Risks you can see coming

Most of what derails a project is visible early to someone. A key person is already booked on another project. A supplier has missed dates before. The approval committee meets once a month. A risk is simply something that might happen and would hurt the project if it did.

At the start, spend half an hour listing what could go wrong, with the people who will do the work. For each risk worth worrying about, note how likely it is, how much damage it would do and one thing you will do about it now: book the person early, ask the supplier for a firmer date, get on the committee’s agenda in advance. Then look at the list again every couple of weeks. Risks change as the work moves, and the list is only useful if it does too.

Choosing how to run it

Teams increasingly mix methods instead of picking one. PMI’s 2024 Pulse of the Profession found that the share of practitioners who always or often use hybrid approaches rose from 20% in 2020 to 31.5% in 2023, while predictive approaches, though still the most common, fell from 58% to 43.9% (PMI Pulse of the Profession 2024).

If you work with software or product teams, you will meet Scrum, the most widely used agile framework. Scrum Without the Ceremony explains how it works, and What a Scrum Master Really Does All Day covers the role at its center.

Tools come last

Tools help, but they do not fix unclear goals or vague scope. A small project can run on a shared document and a spreadsheet. Larger ones benefit from a tool that links tasks to projects and shows who is doing what. If your team already uses Notion, One Workspace for Notes, Tasks and Projects shows how to set it up for project work without building something nobody maintains.

Closing well

The end of a project deserves as much attention as the start. Check the result against the success measures you wrote down, hand over anything that needs looking after, and spend half an hour with the team on what to repeat and what to change next time. Then actually close it. Projects that never formally end keep absorbing time long after anyone is learning from them.

Learn it properly

The free Project Management course on Train Your Skills covers defining success, scope, planning and estimating, choosing an approach, communication and closing, with a practical toolkit and a test at the end of each lesson. Start the course here or browse all the free courses.