A project is temporary work that produces a specific result and then ends. Operations are repeating work that keeps running. The distinction matters because the two need different management. Operations improve through standardisation and measurement. Projects succeed through definition, sequencing and decisions made in time.
The four properties of a project
- It has an end. If it never finishes, it is operations wearing a project name.
- It produces a defined result. A deliverable someone can accept or reject.
- It is at least partly novel. If you have done it identically forty times, it is a process and should be run as one.
- It uses borrowed capacity. People and money are drawn from elsewhere, which is why projects compete and stall.
The three constraints
Every project balances scope, time and cost, with quality as the dependent outcome. The constraint model is simple but brutally useful: you can fix any two and the third must flex. If scope and deadline are fixed, cost must rise or quality falls. If cost and deadline are fixed, scope must shrink. A project where someone insists all three are fixed is not a plan, it is a wish, and quality is where it will fail quietly.
The single most useful question at the start of any project is which of the three is genuinely least flexible. Ask it explicitly and get an answer from the person who owns the budget. The answer determines every trade-off you will make for the rest of the project.
Scope, time, cost in practice
- Scope. What will be delivered, stated as countable items with exclusions.
- Time. Not just the end date but the intermediate dates that others depend on.
- Cost. Money and the often-ignored cost of people’s attention, which is the binding constraint in small organisations.
Worked example
A twelve-person company committed to launching a new service portal by the start of its busy season, with a fixed budget and a scope agreed in a workshop: nine features including a reporting dashboard and a customer messaging module. Six weeks in, two developers were pulled onto an urgent client issue. Management insisted all three constraints held. The result was a launch that technically met the date with all nine features, half of them barely working, and four months of repair work afterwards costing more than the original project. Had the team named time as the hard constraint and cut scope to five solid features, the busy season would have been served and the rest delivered later. The failure was not effort; it was refusing to let any constraint flex.
Common mistakes
- Running a project with no agreed end state, so it drifts into permanent operations.
- Accepting all three constraints as fixed, which guarantees quality absorbs the pressure.
- Ignoring attention as a cost, so people are assigned to four projects at once.
- Treating repetitive work as a project, adding overhead with no benefit.
Action Step
Take a project you are running now and write the three constraints on one page: scope as countable deliverables, time as dates including intermediate ones, cost as money plus named people and their available hours per week. Then ask the budget owner which constraint is least flexible and write down their answer in their words. If you cannot get an answer, that is your first risk.