What Is a Project? Definition, Characteristics, Examples

What is a project?

A project is a temporary endeavour with a defined beginning and end, undertaken to create a unique product, service or result. It has a specific objective, works within limits of time, budget and resources, and is carried out by a team brought together for the purpose. When the objective is achieved, or the project is stopped, the project ends.

In plain words, a project is a one-off piece of work with a goal and a finish line. Redesigning a website, opening a new office, launching a product or running a conference are all projects. Answering customer emails every day is not, because it never ends and each day looks much like the last.

Standard definitions of a project

The main project management standards describe a project in slightly different words, but they agree on the essentials: it is temporary, it delivers something specific and it exists for a purpose.

If you are studying for an exam, learn the PMI wording for the PMBOK Guide and CAPM/PMP, and the PRINCE2 wording for PRINCE2. In practice, all three point you to the same questions: what are we delivering, why, by when and within what limits?

What "temporary" and "unique" really mean

• Temporary does not mean short. A project can last two weeks or ten years. Temporary means it has a planned end, not that it is quick.
• The result can last. A bridge built by a project may stand for a century. The project is temporary; its output is not.
• Unique does not mean never done before. Your company may have moved office three times, but this move, to this building, with these people and this budget, is still unique.
• The team is usually temporary too. People join from different departments or suppliers and return to their normal roles when the project closes.

Key characteristics of a project

Most textbooks list five to seven characteristics. These are the ones that help you recognise a project and plan it well:

1. Temporary: it has a defined start and end date, and closes when the objective is met or the project is cancelled.
2. Unique result: it creates a new product, service, result or change, even if similar work has been done before.
3. Specific objective: there is a clear, agreed goal, ideally written as SMART project objectives.
4. Defined deliverables: the outputs the project must hand over, such as a building, a system, a report or a trained team. See project deliverables.
5. Constraints: limits on time, cost, scope, quality, resources and risk. Changing one usually affects the others; see project constraints.
6. Progressive elaboration: plans start broad and become more detailed as the team learns more, rather than being complete on day one.
7. Uncertainty and risk: because the work is new, projects carry more risk than routine work and need active risk management.

PRINCE2 adds a useful point: projects are usually cross-functional. They draw people together from different teams, departments or suppliers, which is why clear roles, a sponsor and good communication matter so much.

Elements of a project

Whatever its size, every project has the same basic building blocks. Writing each of them down, even briefly, is the quickest way to turn an idea into something you can manage.

Small projects can capture all of this on a single page. Our free project brief template and project charter template are built around these elements.

Project vs operations

The most important distinction in project management is between projects and operations (sometimes called business as usual, or BAU). Operations keep the organisation running. Projects change it.

The two are closely connected. Most projects end by handing their result over to operations: the new payroll system becomes part of the finance team's monthly routine. Planning that hand-over (training, support, documentation and ownership) is part of the project, not an afterthought.

Project vs task, programme and portfolio

People often use "project" loosely for anything from a single to-do item to a multi-year change programme. These are the four levels most organisations use:

A project is made up of many tasks and activities. Several projects may belong to a programme, and every project and programme should fit somewhere in the portfolio.

Why projects are started

Projects do not appear from nowhere. Each one should exist for a reason that matters to the organisation. Common drivers include:

• Strategy: delivering a strategic goal, such as entering a new market or modernising systems.
• Customer or stakeholder requests: a client contract, a new feature customers have asked for, or a request from another department.
• Regulation and compliance: a new law, safety standard or audit finding the organisation must respond to.
• Problems to fix: a failing system, a quality issue or a process that no longer copes.
• Opportunities and new technology: automating manual work, adopting AI tools or launching a new product.
• Social and environmental goals: reducing emissions, improving accessibility or supporting a community.

In a well-run organisation, the reason is written down in a business case, which compares costs, benefits and risks, and the project is formally authorised with a project charter. Our business case template gives you a structure for the first of these.

Types of projects

There is no single official list of project types. Classifying a project helps you choose the right approach, people and level of control.

By industry or field

• IT and software: new systems, upgrades, migrations, apps and websites.
• Construction and engineering: buildings, infrastructure, fit-outs and plant.
• Business change: restructures, new processes, mergers and policy changes.
• Marketing and creative: campaigns, rebrands, product launches and content.
• Research and development: new products, studies and prototypes.
• Events: conferences, launches, festivals and internal events.
• Public sector and community: services, programmes funded by grants and civic infrastructure.

By delivery approach

By size and complexity

Small projects (a few people, a few weeks) need a light plan and simple tracking. Medium projects need a schedule, budget, risk log and regular reporting. Large or complex projects, with many stakeholders, suppliers or dependencies, need formal project governance and may be split into stages or grouped into a programme.

By sponsor and funding

• Internal projects improve the organisation itself, such as a new HR system.
• External or client projects are delivered for a customer under a contract or statement of work.
• Public, private or mixed funding affects approval rules, reporting and procurement.

Examples of projects

These examples show how the same definition applies across very different fields:

Projects are not only for work. Planning a wedding, renovating a kitchen or writing a dissertation all meet the definition: each is temporary, has a unique result and has limits on time and money.

Worked example: an office move

A company of 80 people needs to move to a new office when its lease ends in nine months. Here is how that becomes a project:

1. Initiation: the operations director (sponsor) sets the objective: move all staff into the new office by 30 June with no more than one working day of disruption, within the approved budget. A charter names the project manager and key stakeholders.
2. Planning: the team defines scope (fit-out, IT, furniture, removals, communications), breaks it into work packages, builds a schedule with milestones and agrees a budget and risk log.
3. Execution: suppliers complete the fit-out, IT installs the network, and staff are briefed and packed.
4. Monitoring and controlling: the project manager tracks progress against the plan weekly and handles changes, such as a delayed furniture delivery.
5. Closure: staff move in, snags are fixed, the old office is handed back, facilities take over day-to-day running and the team records lessons learned.

Once facilities take over, the work becomes operations. The project is finished.

Is it a project? A quick checklist

Use these questions when someone hands you a piece of work and you need to decide how to run it. If you answer yes to most of them, treat it as a project:

1. Does it have a clear objective and a point at which it will be finished?
2. Will it create something new or change how things work?
3. Does it need people from more than one team, or an external supplier?
4. Will it take more than a few days of effort?
5. Does it need its own budget, or does it compete for shared resources?
6. Are there real risks if it is late, over budget or wrong?
7. Does someone senior need to approve it or be kept informed?

If most answers are no, it is probably a task or routine work, and a simple list will do; our to-do list template is enough. If the answers are yes but the work is small, run it as a light project: a one-page brief, a short task list with owners and dates, and a weekly check-in.

The project life cycle

Every project moves through a life cycle from idea to closure. The most widely taught model has five phases, based on the PMI process groups:

Agile projects follow the same broad journey but repeat planning, delivery and review in short iterations. PMI's current PMBOK Guide (eighth edition, 2025) organises project work around principles and performance domains rather than a strict sequence of phases, but the life cycle above is still the simplest way to understand how a project runs.

What makes a project successful

Traditionally, a project was judged on the triple constraint: delivered on time, on budget and to scope. That still matters, but most organisations now also ask whether the project achieved the outcome it was started for. A system delivered on time that nobody uses is not a success.

• Success criteria are the measures you use to judge the project, agreed at the start: for example, "all 80 staff working from the new office by 30 June, within budget".
• Success factors are the conditions that make success more likely, such as an engaged sponsor, clear objectives, a capable team and good stakeholder communication. See critical success factors.
• Benefits are the improvements the organisation gets after the project, such as lower costs or happier customers. They are often measured after the project closes.

A skilled project manager keeps all three in view.

Common misconceptions about projects

• "Everything is a project." Labelling routine work as a project adds paperwork without adding control. Keep projects for work that is temporary and unique.
• "A project needs a big plan." The level of planning should match the size and risk. A two-week project needs a page, not a manual.
• "The project ends when the work is done." It ends when the deliverables are accepted, handed over and the project is formally closed. Skipping project closure leaves loose ends.
• "Agile work has no projects." Agile product teams often work continuously on a product, but time-bound initiatives within that work, such as a launch or migration, are still projects.
• "No end date is fine for now." A project without an end date tends to drift and absorb resources. Set at least a target date and review it.
• "The project manager owns the outcome alone." The sponsor owns the business case and benefits; the project manager owns delivery of the project.

Next steps

Once you can recognise a project, the next step is learning how to manage one: setting objectives, planning the work, leading the team and keeping stakeholders informed. Start with a one-page brief or charter, agree the objective and scope with your sponsor, and build a simple plan. Our project plan template gives you a ready-made structure.

Free templates for this topic

Browse all templates

Frequently asked questions