It is absolutely essential before you start looking at the platforms and potential partners that you have a really succinct definition of what the business critical requirements are. This doesn’t mean create a huge three and a half thousand-point checklist of every single last functional element. That comes much later in the project when you’re doing function specifications.

There are so many things in platforms that are just good housekeeping, hygiene factors, for example having a Wishlist and the ability to create multiple Wishlists. A feature like this is highly unlikely to influence platform choice. What is going to influence a platform choice is the business critical capabilities which, depending on the platform you choose, could end up creating a lot of process hassle or additional cost if the platforms do not handle well natively out of the box those capabilities that you need. For example, integrations with ERPs.

So it’s really important that there is a process of stakeholder interview with the key stakeholders from your project team. What do they need from the ecommerce platform and ecosystem? So this means mapping out all of the stakeholders who should be influencing the capture of business critical requirements. This is not jut the ecommerce team who’ll be responsible for managing and trading the website but it’s also areas such as the finance team who’ll be responsible for business report and reconciliation, and the logistics side of the business. It means looking at order management, fulfilment, shipping, returns etc.

Define needs right the way down to retail teams when you’re working in an omni channel environment where those retail teams will have a dependency on the store integration, like click and collect ,or if there’s in store digital points of sale. So it’s essential to sit those people down with a structured interview guide. Ahead of meeting make them aware of what you’re doing and why and provide them with an interview guide that outlines the discussion points that you want to get through with them. Also give them a briefing on what you expect them to bring to the table for those sessions so they come prepared. That makes these sessions far more productive.

Off the back of this, the person leading the interviews, typically either the customer lead or the project manager, will document the requirements that are being captured and then review, edit and play those back to the business stakeholder so the business stakeholder can review, edit if needed and then sign off and say “Yes that’s an accurate statement of the business critical requirements”. These requirements can then be reviewed with senior managers and the Project Sponsor if needed depending on the size of the organisational project team. Fundamentally, captured requirements should be played back to the business sponsor to say , “This is our ground zero business critical requirements is there anything in here that you want to contend? Is there anything in here that doesn’t fit with our agreed definition of scope and our MVP approach to this project?”.

Make sure you use a consistent format for documenting requirements. Use cases and user stories are proven ways to do this and the added value is that they can be expanded when moving into project delivery to create the detailed user stories to feed the development sprints.

Your documented business requirements are the elements you will then take forward to the next step of the project, which is going to be platform evaluation and shortlisting. So it’s really important there is a structured process, an agreed format for documentation, and that you also define your business prioritisation because you can then ensure that a business critical requirement is genuinely a business critical requirement.

Hopefully that’s given you some useful insights that you can take away, thank you.