Join Paul and James, two experienced ecommerce professionals, as they explain the role and importance of a Statement of Work in ecommerce replatforming projects.
Listen on your favourite player
Watch the video
A Statement of Work is an essential document for any project. It defines the scope of deliverables and provides context for what functionality the solution provider will deliver and the associated fee schedule. You need a detailed SoW because without it, you open yourself to risks later in the project, such as unforeseen costs from assuming an item was included in scope but it wasn’t documented. For a replatforming project, we advise to get a detailed set of requirements defined and prioritised before engaging with an agency partner, as this will improve the focus and output quality of their Discovery process.
Tl;dr: what we cover:
- What happens when your SoW isn’t accurate
- How to get your SoW right and what to include
- Tips for navigating supplier proposals
Key Discussion Points
What can go wrong when the SoW isn’t fit for purpose?
- Important requirements not documented, which will result in cost creep later on or stakeholder dissatisfaction e.g. basics like Google Maps integration and ability to have unique indexable URLs for each local store with CMS manageable pages
- Forgetting to include something that’s important for the overall CX and will materially impact quality of the solution e.g. accessibility
- Insufficient detail meaning developers provide a solution but it fails on one or more ecommerce criteria such as UX e.g. Wishlist user journey for creating, adding to basket, updating, saving etc.
- Not being precise enough about what is being done so the outputs don’t align with business expectations e.g. for one client, the definition of the design phase was limited, it didn’t specify all page types and only had 1 round of iterations + no reference to wireframing before visual design
- Missing project milestone deadlines because one or more parties aren’t prepared or added complexity is identified during the build phase because the requirements weren’t articulated clearly
- Finally, it will lead to arguments and emotive conversations like “you said you’d do that, “ but it’s not in the SoW” – this erodes trust, damages the relationship and wastes time.
How do you decide what goes in a SoW?
- It starts with a clearly defined scope and prioritisation – this governs the high-level capabilities that must be in the SoW
- Internal mini discovery is the best way to ensure you have a documented set of requirements and features against which to evaluate the SoW
- Also means you can brief your supplier and give them a meaningful set of criteria; we like creating ecommerce capability maps as visual guides
The following elements are essential, in addition to financial content like the fees & payment schedule:
- Technology stack being used including versions where relevant, what’s the ecom application, front-end etc. e.g is it headless, is it a PWA, SPA etc.
- Solution design and integration paths e.g. use of APIs, direct connectors, middleware etc.
- Which integrations are included and the detail for each i.e. how will ecommerce platform be connected to ERP for product, customer, order data flows and real-time updates
- Design & UX: what’s included, which page types, wireframing, interaction design, iterations etc. (one project where page transitions weren’t referenced, Client then expected animations to be shown during design phase but this was additional cost)
- Page by page features and capabilities (homepage, navigation, category landing pages, PLP, PDP, basket & checkout, My Account etc.) & site-wide elements e.g. navigation menus
What core ecommerce capabilities should you look out for?
The list below is by no means exhaustive but gives a good indication of the depth and breadth of thinking required when polishing your Statement of Work. Please bear in mind that the range of topics is influenced by the type & size of business.
- Data migration
- Internationalisation: site versions & phasing, domain structure, localisation
- Trade
- Tax & duties
- Stock management
- Shipping & returns
- Product catalogue management
- Pricing management
- Payments
- SEO: technical e.g. schema.org and marketing e.g. on-page snippets (inc. international provisions)
- Merchandising/trading
- Personalisation
- Search & Browse
- Digital marketing e.g. data feeds & marketplace integration (specify if it’s API vs. pixel tracking)
- UGC e.g. reviews
- Product related content e.g. size guides
- Blogs
- Analytics
- eCRM
- User management
- Compliance e.g. GDPR, PCI
Edge case use case examples that are project specific:
- Donations for Charities
- Subscriptions
- Product configurators
- Single sign-on
- AR/VR
- Native apps
- Live Shopping
Also make sure the following project items are covered:
- What’s out of scope and why
- Project management and delivery
- Resources and roles
- Development phase & sprints
- Development standards & controls
- QA
- PM tools & documentation
- Account management provisions
- Training: what’s covered, what’s additional/optional
- SLAs and ongoing support costs
- Line by line cost model and payment schedule
- Ts & Cs
Want to suggest a topic or guest for a future episode? Contact us via the website or on Twitter.
