Defining the scope of a project

Defining the scope of a project

Defining the scope of a project 860 489 Border Crossing UX

Now first off I want to state that I have learnt this the hard way. There was no epiphany this is just something I’ve learnt by being burnt.

At the start of any project you will try to define the scope of work required. This usually involves defining the deliverables the client needs and breaking these down into the tasks required to deliver them.

Why do this?

  • To manage client expectations
  • To establish clear communication
  • To ensure you can deliver what you say you will (on-time and on-budget)
  • To identify the areas you really can add value
  • To help the client prioritise what it is that they really need


What does this involve?

Well I reckon it all boils down to the following:

  • What are the project’s SMART objectives?
  • What are the client’s business goals?
  • What are the client’s needs (short and long-term)?
  • What are their target audience/end-user goals?
  • What are their target audience/end-user needs?
  • What are the client’s constraints (budget, resources and timeline)?
  • Details of the work to be done.
  • What research has been done to inform the above?
  • Why do they want to work with you in particular?
  • How will they measure success?

Now a well written brief should detail all of the above quite clearly.

However, I’ve seen a lot of briefs recently that look more like a wish-list then a strategic document.

How do we address this?

We are honest and direct and rarely take a brief as is.

We analyse it, critique it and pass on our feedback to potential clients.

There is no doubt that this approach may well have compromised our chances of securing a number of contracts.

Then why do it?

Two reasons:

  • it provides genuine value to the client
  • it ensures you don’t find yourself wishing you had once the project kicks-off.

After all you know what can be done, how well it can be done, and how much risk is involved.

As such I see it as our duty to:

  • provide feedback on what is, and what isn’t doable within the constraints of the project
  • go through their requirements and reassess the prioritisation of the work to be done.


If you know a decision they are taking now is going to have long-term implications state them up-front. This is what clients are hiring you for, not just the fulfillment.

Yes, it may be a difficult conversation but if you don’t do this you will certainly come to regret it.

Bottom line it’s better to miss out on a job then find yourself working on one you can’t wait to see the back of.

Not only can you take a financial hit on projects such as these, the impact on your team’s morale can not be underestimated.

Back to top