Project scoping
Know what to build before committing your budget.
Business workshops, feasibility assessment and a delivery roadmap: we prepare the decisions and documents needed to launch your project.
Services you can engage us for
Scoping can be a standalone engagement, with outputs your team or another delivery partner can use.

Functional scoping
We run workshops with your teams to define users, journeys, business rules and the first delivery scope.
Deliverables : Requirements, prioritised scope and acceptance criteria.

Feasibility & solution selection
We compare existing tools, SaaS and custom software, then assess data, integrations and technical constraints. A targeted experiment can complement the assessment.
Deliverables : Options assessment, risks and assumptions to verify.

Roadmap & delivery preparation
We sequence releases and dependencies, clarify responsibilities and estimate effort against explicit assumptions.
Deliverables : Delivery roadmap, initial backlog and scope-dependent estimate.
An approach tailored to your engagement
We agree the steps needed for your scope. An audit or assessment can be commissioned separately, without committing to implementation.
01. Establish the facts
Targeted interviews, a process walkthrough and authorised examples. Deliverable: current process map and observed problems.
02. Test the options
Compare routes and test the riskiest assumption. Deliverable: decision record with limitations, dependencies and unresolved questions.
03. Shape the first release
Set acceptance criteria and release order. Deliverable: estimable scope, ownership and decision points.
Illustrative example, not a client engagement
Automating margin reporting
Illustrative example: the sponsor requests a dashboard, but most effort goes into correcting product-to-cost mappings. Scoping separates calculation, reference data quality and visualisation. The first release can address data reconciliation before expanding reporting.
Before you start
Do we need a specification first?
No. A concrete example, an observed problem and a sponsor who can make decisions are enough to begin. An existing specification becomes an input to validate.
Must Polygon deliver the project afterwards?
The package should be usable independently. Deliverables, usage rights and handover arrangements are specified in the proposal.
Will we receive a fixed price?
Scoping clarifies scope and unknowns. A fixed commitment depends on stable requirements and dependencies; remaining assumptions belong in the estimate.
What happens after delivery?
Your team or another supplier can use the scoping package. If Polygon builds the solution, assumptions become checkpoints: a changed source or business rule requires an explicit scope, budget or schedule decision.
What determines the budget?
Journey variety, stakeholder numbers and data access determine scoping depth. A focused technical experiment may be needed before an estimate is reliable enough to commit to delivery.
Discuss your project
Set your project on solid foundations.
Describe the problem, the teams involved and the decision you need to make. You do not need a specification for this initial conversation.

