2. Getting your objective and scope clear
A project stands or falls by what is put on paper in the first few weeks. Not the planning, not the risk matrix, but the agreement on what you are actually going to do and why. This is where most projects already go wrong, and rarely because people are lazy. It happens because everyone assumes it is obvious. And it seldom is.
After this chapter:
- You know what the definition phase delivers and why that phase determines the rest.
- You can turn a vague wish into an assignment brief using the three clarifying questions.
- You know the difference between the assignment and the goal, and why that distinction matters.
- Can you formulate an objective in SMART terms.
- You can mark out a scope with an in list and an out list, and recognise scope creep.
From vague wish to clear assignment
A project often starts with a remark in the corridor. "We really must do something about customer satisfaction." Or: "It would be good to have a new intranet before the summer." Those are not assignments, they are wishes. Your first task is to unpick that wish, and three questions are enough for that.
What is the problem or the reason? Why is this coming up now, and what happens if we do nothing? What has to be there at the end? A report, a working system, a trained team, a decision? Who are we doing this for? Who will use it later on, who is the client, and who has an interest in it succeeding?
Only once you have a concrete answer to all three can you start formulating. If you rush ahead to planning or dividing up tasks before this is in place, you are building on quicksand.
Ask the why question at least twice. The first time you get the symptom, the second time the real reason. A client who says "we want a new website" usually wants "more enquiries" or "a more serious image with large customers". That is something else entirely, and it calls for a different project.
The assignment statement
The assignment statement is one compact paragraph setting out what the project involves. It answers four questions: what, why, for whom and when. Two to three sentences is enough. The test is simple: read it out to someone who has never heard of the project. If that person understands what it is about, it is a good statement.
Vague assignment: "We are going to improve customer service."
A sharply formulated assignment: "The Customer Service 2.0 project will deliver a fully configured ticketing system before 1 October, enabling the ten staff of the Support department to answer incoming customer questions within 24 hours. The reason is the rise in the number of complaints about response time over the past quarter. The client is the Customer Service manager."
Look at what those three sentences contain: a deadline, a concrete result, a target group, a measurable requirement, a reason and a client. Six elements. That is the level you are working towards.
Assignment and objective are not the same thing
The assignment tells you what you are going to deliver. The goal tells you why, and what effect you want to achieve with it. That difference seems small, but it is the most important distinction in this chapter. Delivering a ticketing system is the assignment. Reducing the average response time from 72 to 24 hours is the goal.
Why that matters becomes clear as soon as you have to choose. Suppose a supplier offers a cheaper package halfway through that works fine technically, but whose reporting is thinner. Is that allowed? That does not depend on the assignment, but on the objective. If that reporting is needed to manage response time, then no. If it is merely nice to have, then yes. Without an objective on paper, a question like that becomes a matter of who talks loudest.
Making the goal SMART
"Improving customer satisfaction" is not an objective but a wish. To turn it into an objective, you use SMART. Specific: concrete about what you want to achieve, for whom and where, with no room for interpretation. Measurable: a number, percentage or observable fact tells you whether it has been achieved. Acceptable: those involved are behind it, because an objective nobody wants is rarely achieved. Realistic: achievable within the time and resources available; ambitious is fine, impossible is not. Time-bound: there is a fixed end date or a fixed point of measurement.
Not SMART: "We want to shorten the turnaround time for quotations."
SMART: "By the end of Q3 2027, 80 per cent of quotations will be sent within 5 working days of the first customer contact, measured across the sales team of the Noord department."
The difference lies not in the ambition but in whether it can be verified. With the second formulation, you will know in October 2027 whether you have achieved it. With the first, that remains a matter of opinion.
Scope: what is in and what is out
A clear objective is a strong start, but without boundaries a project remains open-ended. The scope determines which elements you take on and which you leave alone. That sounds simple, but in practice a scope grows without anyone noticing. Someone asks whether you could "just" include a second department as well. The steering group feels an extra report is "only logical". Before you know it you are dealing with scope creep: you keep doing more, with the same time and the same budget.
The antidote is an explicit list of what falls outside the scope. It is just as important as the in list, and it feels slightly unkind to write down. Do it anyway. By naming things literally you prevent discussions afterwards, and you show that you have thought about where the project stops.
A wholesaler is introducing a new customer tracking system for the Sales department. Within the scope: setting up the system, the link with the current customer database and training the twelve people in the sales team. Outside the scope, written down in exactly those words in the project plan: the link with the financial administration, training other departments and the mobile app. Three months later the controller asks whether the link with the administration "can't just be added". The project manager can now point to a single line, and it is treated as a new request with its own budget rather than as self-evident additional work. That saved an estimated six weeks of work in a five-month project.
Constraints: hard and soft
Constraints are the ground rules set by the client and the organisation. They usually concern time, money, quality and capacity, and sometimes specific requirements are added: legal frameworks, technical standards, existing contracts with suppliers.
Distinguish between hard and soft preconditions. Hard means non-negotiable, such as a statutory deadline or a fixed budget. Soft means desirable but open to discussion. By making that difference explicit, you know where you have room to shift things if the going gets tough, and you would rather know that in advance than at the moment itself.
The project plan and sign-off
With the goal, result, scope and constraints on paper, you have the building blocks for the project plan. That plan is two things at once: the written agreement with your client, and your own compass during delivery. For a small internal project five to ten pages are enough; for a large programme it becomes thicker.
The plan only acquires value once the client formally signs off on it. From that moment on it is your point of reference. If a change comes along later, you go through the plan: what does this change about the objective, scope, schedule or budget? A change that is not recorded almost always leads to discussion at the end, usually at the worst possible moment.
Take the project you chose in chapter 1 and write down, on no more than one A4 page:
- The assignment statement in three sentences: what, why, for whom, when.
- The goal, formulated in SMART terms. Which figure is going up or down, and when do you measure it?
- Five things that fall within the scope and five that explicitly fall outside it.
- The three most important preconditions, stating for each whether it is hard or soft.
Then put it to your client or manager. Pay particular attention to the out list; that is usually where the surprises come from.
Summary
- The definition phase lays the foundation: assignment, objective, scope and preconditions are on paper before you start planning.
- You move from wish to assignment with three questions: what is the reason, what has to be there at the end, and who are we doing this for?
- A sharp assignment statement answers what, why, for whom and when in two to three sentences.
- The assignment is what you deliver, the goal is the effect you want to achieve. At every choice along the way, the goal is your yardstick.
- SMART makes a goal verifiable: specific, measurable, acceptable, realistic and time-bound.
- Scope sets the boundaries. The out list is just as important as the in list and is your best defence against scope creep.
- Constraints are either hard or soft. Know in advance where you have room to manoeuvre.
- The project plan only becomes a point of reference once the client formally approves it.
A project delivers a new ticketing system in order to bring response time down from 72 to 24 hours. What is the objective here?
Why does a project plan include a list of what falls outside the scope?
Which objective is formulated in SMART terms?