10 Tips for Capturing Business Requirements Effectively

Hello and welcome to episode six of the Re:platform podcast. Today it’s just myself, James, and I’m going to be talking about the fascinating topic of running effective stakeholder requirements gathering sessions.

This concerns the initial phase before you consider which platforms could be relevant to the business or decide how you can evaluate the platforms. I’ve got 10 key tips based on projects I’ve worked on over the years that help make this process more effective, helping you to properly engage your stakeholders, set clear boundaries and get as much out of it as possible. It will also ensure you don’t lose sight of what you’re trying to do. Hopefully these tips will be self-explanatory, but if not, as always on these podcasts, feel free to get in touch afterwards and ask as many questions as you like. Okay, let’s go through the 10 points.

#1 – Engage with all relevant stakeholders

I’ve worked with businesses where people have underestimated how many different stakeholders need to be involved; they think one or two can cover off all of the questions and answer on behalf of colleagues. This is dangerous for two reasons.

Firstly, we often think we know more than we do and that we understand other people’s roles better than we actually do. So we could miss critical information if we rely on a limited stakeholder set. We might not be able to articulate what the need is effectively enough and misunderstand what is required by business users.

Secondly, if you don’t engage with stakeholders, you’re not bringing them into the process from the start. You want people to buy-in to this process so that they feel like they’re contributing but also so that they’ve got a stake in the project. This is really important because when you start to talk to people about a solution and whether it’s right for the business and fit for purpose, if they’ve had no involvement, they don’t even know why this solution is being presented to them. This can put people’s backs up. It also makes it harder for you to convince them that the solution they’re looking at is relevant to them, their job, and can resolve issues that frustrate them.

So make sure you engage everyone. It doesn’t mean you have to involve everyone in every single discussion; some people can be involved for a short amount of time, others for a longer period. The most important thing is, make people feel part of the overall project, that they can influence the outcome.

#2 – Set clear boundaries and expectations for requirements gathering

The second thing that’s linked very closely to this is if you involve multiple people, you have to be very clear on the boundaries of the project and the process. When you’re doing requirements gathering, it’s important to establish in people’s minds what you’re trying to do and what you’re not trying to do.

This is not the stage where you go into the nth degree of detail to build out complex functional specifications for exactly how things work or to define a solution to a problem. The aim here is to understand what the business needs to achieve in the context of an ecommerce platform. Therefore, what does that platform need to enable? So these are high level comments. Take international as an example; specify in the different site versions required, multiple currencies, what languages need to be enabled from content point of view, which payment methods need to be provided to provide the best customer service across the different countries you’re selling to.

What you don’t need to do is define the ‘how’ at this stage, for example how would you launch a new site local country storefront. You will get to that during the platform evaluation stage. Don’t worry, that detail has to comes later on in the process but you’ve got to make sure during requirements capture that the high level requirements of the business are clearly understood (‘what’ and ‘why’). To achieve this, set clear boundaries, tell people what the scope of the project is, tell them what it isn’t.

If you’re approaching project delivery from an MVP point of view, which is pretty standard in replatforming projects because they’re quite complex, set a clear expectation about what is going to be delivered within the available budget for the phase one MVP launch. It might be that a business wants to integrate a new enterprise CRM into the tech stack but that’s a separate project and the scope of deliverables for ecommerce doesn’t include the new CRM integration. If this is the case, communicate clearly to stakeholders that the focus is bedding a new ecommerce platform into the existing business processes and then in a subsequent phase to integrate with the new CRM.

Setting the expectations clearly up front helps people buy into a process and get excited about a new platform, what it could deliver. This is much better than giving them an open book and then they find out later on that the new ecommerce platform doesn’t deliver what they thought it would. This can make it harder to get them engaged with the new tools and technology and the new processes. So at least by telling them what it is and what it isn’t, you enable them to understand what they should focus on.

If they want to challenge the scope and focus, they can go to their senior managers and articulate why they think the project isn’t going to deliver what is needed to support business goals.

#3 – Clear discussion guide for workshops

Create a succinct brief and discussion guide for every single conversation, whether it’s a face to face workshop or a remote video conference, phone call, et cetera.

• Make sure everyone who’s invited knows why they’re there.
• Each session should have a clear goal and set of objectives.
• Define discussion points that set an outline for what you want to achieve.
• Define workshop outcomes so people know what success looks like.

Be as clear as possible with people; get information to them in advance. If there’s any pre-work or there are materials you want them to bring along to help facilitate discussion, brief them on that as well and give them enough time to prepare. A good example, on a big project I worked on with House of Fraser, when we were looking into some of the content management requirements, we asked the content team to come with an overview of the current content production processes and walk us through a step by step process for creating content, uploading, editing and publishing.

You’ve got to give people time to get that information ready. Don’t just send them an invite for a meeting in the morning and expect them to bring loads of process documentation and to have thought clearly about new requirements.

#4 – Focus on agreed outcomes

When you’re going through these workshops, don’t lose sight of what you’re trying to achieve. So as the person who is either the project manager or the business lead, don’t allow discussions to go down a rabbit hole. Getting sidetracked is an inevitable human tendency. I’ve been involved in discussions where we’ve been talking about product catalogue management, then people have gone off on a tangent to talk about how they do range planning and product sourcing. You have to bring people back to the goal of the session and park non-essential discussions.

So if there’s an important discussion that the business needs to follow up on, for example it’s process-related and that process needs to be defined because it then enables the core platform capabilities, make sure the discussion point is captured and put onto an action log for follow-up. Focus the workshop discussions purely on the requirements that you need to capture that are going to influence which technology is fit for purpose.

Never lose sight of the fact that requirements gathering is designed to provide a framework of needs around which to assess platform fit.

#5 – Document actions and dependencies

Capture dependencies and actions that need to be taken to enable you to get to the point where you have a accurate set of high level requirements that can be signed off by the business. So by dependencies I mean, for example, other projects that will have a dependency upon the ecommerce replatforming. For example, there’s a parallel CRM project and the CRM platform decision is due to be signed off in the next few weeks. That’s important to know because from an ecommerce platform point of view, you’d obviously want to look at vendors that fit your requirements needs and have proven connectors or integrations with the chosen CRM because that can reduce risk and take some of the complexity away. Working with the business to understand how decisions made in other projects or parts of the business would impact the ecommerce platform selection is invaluable.

So dependencies are important to track. If there are discussions coming up where there’s dependency on a person or another part of the business where follow-up is required, make sure that’s captured as an action and then that can be taken to other stakeholders to to resolve outstanding questions.

#6 – Focus stakeholders on the ‘to be’ vision for ecommerce

During these sessions you get through a lot of information and the tendency amongst stakeholders is just to think about how they do work now, the ‘as is’ process but not the ‘to be’ world. You want them t consider what operating model they need to unpick known inefficiencies or improve the capabilities that they’ve currently got.

A good technique is to politely challenge people by saying, “OK so this is how we do it now but how would you like to do it in the future if you didn’t have the current systems/process constraints?”. The role of the facilitator in this process, whether that’s an external facilitator or it’s yourself within your business, is to challenge what people think and probe them to consider how they could do things more efficiently. For example, what have you learned in other businesses and what do you know that competitors do that would enable the business to improve?

This could be unpicking manual processes and turning them into automated workflows to save time and allow a new platform to add value rather than replicate tedious, unnecessary manual activities. It’s about not replicating things that aren’t efficient. So I’ll give you a couple of examples from projects I’ve worked on.

In the context of content management, encouraging people to think about not just what they manage at the moment but other areas of the website that they should content manage that would free up development time. An example is forms where form field labels and text are hard coded. If the business wants to change the label it requires development effort. So challenge that thinking and say, what should we unpick within a new solution?

For another Client, they couldn’t do any editing via CMS of the main navigation menus. So again, if they wanted to change the menu hierarchy, labels and dropdown menu content, they had to go to the IT team to request a change. Then it goes into a queue, has to be QA tested, released, et cetera. Encourage stakeholders to think about what control they need to self-serve effectively and minimise demands upon internal and external IT resource for simple BAU tasks.

#7 – Understand & define business processes

As you go through this, lots of business processes are discussed whether it’s the creation and uploading of products, management of content, publishing of content or launching big campaigns. Lots of processes are required to enable ecommerce platforms to work effectively. It’s critical not just to accept that there is a process but to clarify how it works.

Is there anything unique to the business that has to be done that if it isn’t done this way, creates an operational inefficiency or makes it harder to service customers? You should to normalise processes as much as possible, in terms of how ecommerce platforms and other systems work by default, but you also need to not disadvantage the business. If customisation has happened for a very good reason, ask for an explanation about the process, make sure you’ve understood at a high level what those processes are, who gets involved and what the role of the ecommerce platform is in that.

Often decisions have been made in the past to do something in a particular way. And I’ve seen this around how product catalogues are architected and how products are configured in terms of parent and child products and the use of attribute data. Was that decision made because of a limitation or a lack of resource, or was it made for a specific business need? Don’t just replicate because that’s the ‘as is’ process; challenge whether that process and way of doing it needs to be rethought, in terms of automating what’s manual or freeing up time of expensive specialist resource like developers to focus on value add projects.

#8 – Validate the importance and priority level of requirements

Learn to validate the business importance of requirements that have been specified. If somebody is saying that they want to do something differently or enable something new, you need to understand how important it is. What is the business need? Is it simply that somebody likes the idea of doing it or is there a genuine business case that’s been put defined?

This helps in terms of prioritisation of what you need to consider within the MVP capability versus what might come later. And when you’re evaluating a platform, you’ve got to look at the MVP implication plus the demands of later phases to understand how easy it will be to deliver the future roadmap.

It’s important to challenge people in a positive way. It doesn’t mean making people feel that what they’ve said is nonsense. It’s more about asking what has driven that business need –  is it customer need? Is it your individual need? Is it about cost efficiency? Is it a revenue opportunity? You know, what, what is the information you could provide to help us get better context for it?

#9 – Set clear expectations for the outcomes of workshops

At the end of each of these sessions, be very clear with attendees that the aim of the process of requirements gathering is not to guarantee that they will get everything they’ve requested; it’s about understanding that you’re channelling business needs into a pot that will be evaluated in the context of agreed scopes and budget.  The project team will then look at what must be be enabled versus what else the business wants to achieve but may not be able to afford to, or there isn’t a strong business case that can be approved.

Inevitably, some things come out of this that aren’t related to the ecommerceproject deliverables. I’ve seen this before where people have talked about inefficiencies in warehouse processes. Now that’s not an ecommerce dependency; that’s warehouse management systems and back office processes come into play. Ecommerce will not fix and resolve issues like this, so it’s important to be clear with stakeholders what will be tackled and what won’t.

Set clear expectation for stakeholders e.g. here is the scope we are working towards, we’re not going to ignore your requirements but please realise that some of the things you talked about will not be fixed by this project. These can be captured and added to an action and issues log for follow up.

There’s nothing worse than people getting a new shiny bit of kit thinking that it’s going to solve all their woes and realize that the same processes still exist and they can’t do what they expected to. However, it’s nothing to do with the technology, it’s a business constraint.

#10 – Play back requirements for review and approval

This is the last but by no means least tip; when you’ve gone through this process, talked to people and captured a lot of information, you then need to play this back to the stakeholders. Play back what you’ve learned and the requirements you’ve defined in writing to all those stakeholders. Ask them: “Is this now an accurate portrayal of what we discussed. Have we missed anything? Is there anything inaccurate and doesn’t represent what you, what you needed?”.

Play it back and get them to sense check all documentation, then appoint someone to sign it off; this makes people feel involved and ensures you’ve properly understood what they need. Secondly, it gives them accountability because they need to take ownership. Business stakeholders needs to take ownership of their requirements and understand that what they’ve approved will influence the platform selection. Then they can’t turn around later on in the project and complain that they weren’t properly consulted, or what they requested wasn’t fully understood.

This isn’t about finding people out or telling people off. It is purely to give visibility, transparency and accountability to the project. If you put junk in at this stage, you get a completely warped evaluation of the platforms because you’re doing it based on requirements haven’t been validated effectively.

Hopefully that gives you a good set of criteria against which to structure and plan requirements gathering workshops for a re-platforming project. If you capture high quality, relevant requirements, it will help the project team to shortlist relevant platform technologies that would fit with business needs.

If you’ve got any questions, do drop me a line. And if you want to hear about future podcasts, please sign up for the newsletter on the website. Alternatively you can sign up to the RSS feed. There’s a link on the website to that as well. Thanks so much for listening.