How To Make Sure Your Statement of Work (SoW) Is Fit For Purpose
Home » Podcast library » Replatforming advice » How To Make Sure Your Statement of Work (SoW) Is Fit For Purpose

How To Make Sure Your Statement of Work (SoW) Is Fit For Purpose

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.

  1. Data migration
  2. Internationalisation: site versions & phasing, domain structure, localisation
  3. Trade
  4. Tax & duties
  5. Stock management
  6. Shipping & returns
  7. Product catalogue management
  8. Pricing management
  9. Payments
  10. SEO: technical e.g. schema.org and marketing e.g. on-page snippets (inc. international provisions)
  11. Merchandising/trading
  12. Personalisation
  13. Search & Browse
  14. Digital marketing e.g. data feeds & marketplace integration (specify if it’s API vs. pixel tracking)
  15. UGC e.g. reviews
  16. Product related content e.g. size guides
  17. Blogs
  18. Analytics
  19. eCRM
  20. User management
  21. Compliance e.g. GDPR, PCI

Edge case use case examples that are project specific:

  1. Donations for Charities
  2. Subscriptions
  3. Product configurators
  4. Single sign-on
  5. AR/VR
  6. Native apps
  7. 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.

Listen / Subscribe