Project scoping
How an ambition becomes a clear piece of work, with the price and the boundaries agreed first.
Describe the change you want
A good brief says what should be different when the work is finished. Instead of asking for a better dashboard, tell us the decision the dashboard has to support and the information that is missing today.
You do not have to solve the problem before you bring it to us. A plain account of where things stand, one example of the difficulty and a picture of the result are enough to start.
What a scope holds
- The intended result
- What a customer, a team member or you should be able to do at the end, described as one complete journey.
- The included work
- The deliverables, the systems and who is responsible for each. A website and the process behind its inquiry form are two different things, and the scope says which is in.
- The boundaries
- What is left out of the first version. Saying it early stops an assumption from turning into a surprise.
- The way to review it
- How we will both know the work meets the scope. A working journey, a set of test cases or a review of agreed content.
What the work depends on
Content, access, decisions and existing systems all affect delivery. We name who provides each one and what waits on it. A date without those is a guess.
If an ordering system has to stay, or one person has to approve anything customers read, tell us early.
When the plan changes
Building teaches you things. When it does, we separate a correction inside the agreed work from a new request or a change of direction.
Scope, price, responsibilities and terms are agreed before we start. Anything that moves them gets a conversation first. New ideas are welcome. We just make sure the work and the expectations still match.
Ready to talk about your business?
Start with a free audit