project

A temporary effort with a start, an end and a defined result, as opposed to ongoing operations. It ends when the result is accepted or when someone decides to stop it.

A project is temporary work that produces one defined result. It has a start, an end and something specific that exists once it is done: a new subject on sale, a migrated system, an office that has moved. It ends when that result is accepted and handed over, or when someone decides to stop it. It does not end just because a date on the calendar has passed.

Most organizations run three kinds of work at once. Operational work repeats with no planned end: paying suppliers, answering support, delivering the service every day. Product work keeps improving a living product: it has goals each quarter but no finish line, because the product keeps changing. A project sits between them: it borrows people and pieces of the organization for a while and gives back something operations can run.

The project frame (a brief, one owner, a plan, a closing) pays off when three things meet: a fixed date, a one-time result and several people who must hand work to each other. Without them the frame is ceremony: a two-day fix by one developer needs a task and an owner, not a kick-off and weekly status meetings.

The opposite mistake is common too: wrapping continuous product work in an invented deadline. "Make the recommendations better by 15 December" has no finish line, so the team either declares a fake "done" and stops improving, or the date slips and deadlines lose their meaning. Frame only a one-time piece inside such work, with a result and a real date.

Example

Klasna, an online tutoring school, decides to add Physics exam preparation. In October 2026 nothing exists: no tutors, curriculum, diagnostic test or page. Classes must open on 1 February 2027, before the spring exam season.

All three signs of a project are there: a one-time result (a physics subject Klasna can sell and teach), a fixed date, and several people who wait for each other (the academic lead writes the curriculum, the platform lead builds the test and the landing page, tutor operations recruits and onboards tutors, marketing finds learners).

Activity at Klasna	What ends it	Kind of work
Launching physics	The subject is accepted and handed over	Project
Moving every tutor to the updated contract before 1 January	The last tutor signs	Project
Paying tutors twice a month	Nothing: the cycle repeats	Operations
Improving the booking flow	No end date: new goals each quarter	Product work
Teaching physics after 1 February	Nothing: it is now everyday work	Operations

The project owns only the piece of the booking flow that physics needs (physics bookable before classes open); the booking flow itself stays product work. The launch closes in March 2027, after the first weeks of classes, with a check against its success criteria; teaching physics carries on as operations.

Common mistakes

An invented deadline on continuous work. A living product has goals, not a finish line; a fake date produces a fake "done".
Ending at a date, whatever the state. A project ends when its result is accepted and handed over, or when someone decides to stop it.
Keeping operations inside the project. Once the result is handed over, the everyday running of it belongs to operations, not to the project team.
The full frame for small work. One person and two days need a task and an owner, not a brief and status meetings.
Taking over shared systems. A project owns only the piece it needs from a shared system and hands everything else back.

Learn it in the course

Project, operations or product work? · What makes work a project, how it differs from operations and product work, and when a project frame only adds ceremony.
Break the work down from deliverables · Deliverables first, tasks second: a tree that covers all the work of the physics launch and nothing twice, flattened into a list with owners and effort ranges.
Acceptance and handover to operations · Run the acceptance checks against the real thing, write known problems down with owners, hand each part to an everyday owner and keep a runbook for outages and alerts.
The benefits check and a blameless retrospective · Check the result weeks after launch against the success criteria, run a retrospective on facts and decisions, turn lessons into owned actions and close with a one-page report.
Roles: sponsor, lead, expert, one owner per task · Who decides, who does and who is consulted in a small team where one person holds several roles, and a light responsibility table with exactly one owner per task.