What is Discovery?

Hello and welcome to the second part of my ecommerce replatforming series. In this, I’m going to be focusing on the discovery phase. This is what happens after you’ve gone through your vendor and SI partner selection. If you’re interested in vendor selection, there’s a complimentary series of 10 videos that will guide you through that – check out the masterclasses.

The first thing is to establish what discovery is. So when you’ve gone through vendor and SI selection, you’ll have identified high-level requirements and scope. You would also have looked at cost models and done weighted evaluations of both vendor platforms and the SI implementation partners to determine what is the right project solution and also who’s the right partner to implement for you.

However, what you won’t have done, or what most projects won’t have done, is gone into the Nth degree of detail in terms of functional requirements. It’s critical to establish functional requirements because without a set of functional requirements that map out exactly what the solution has to deliver across all the different eCommerce capabilities that you need in order to go live for your MVP or your phase one launch, then there is not enough information to pass through to development teams to set up user stories to put tasks into sprint.

So discovery is the bridge between finding your vendor and the partner to having the right amount of information that enables development teams to go out and actually build what you are paying for. Why is this important? Well, the most important thing of any new platform is that when it’s going to go live that you have an objective set of criteria against which to evaluate that platform and make sure it is ready for go live. Discovery enables you to do this because it guides you through a process of workshops to help you map out the functional requirements from all different areas of the business, detailed them, define them in a language that is usable by development teams, push them through to development queues. And then it gives you a set of criteria from a user acceptance testing point of view. Because you have signed-off requirements that you can go back to and say, “Does this solution now deliver against these requirements? Does it deliver exactly how we wanted these requirements to work?”

That enables much smarter UAT (user acceptance testing) because you’re not just looking at a website. And oh, okay, a wishlist works, it looks good. You’re going back to that wishlist and saying, “Okay, well we have 14 individual requirements for this wishlist.” Do all of these use-cases work? Are all them effectively satisfied both from the end user, the customer point of view, and from your business point of view? And this is why discovery is such a critical phase of any project.

The aim of discovery is to ensure that all stakeholder functional requirements that will be the basis of what the platform delivers are captured. And that those requirements are signed off effectively so that the business has something against which to assess whether it is ready for go live or not.

It also makes it far easier for development teams to know what they’ve got to deliver to the stakeholders instead of getting into this endless circle of,
“Well, that’s not what I wanted,”
“Well, that’s what we thought you meant.”
“No, this is what I meant.”
“Okay, now we’ve built this for you.”
“Well, actually we really wanted it to work like this.”
And that lack of clarity creates a lot of headaches and unnecessary time wastage, and therefore scope creep and budget creep.

There are four additional videos in this series. And what I’m going to walk you through is how to do effective planning for Discovery. How to make those workshops incredibly productive and how to make sure people are prepared for them and understand what’s expected of them. How you then define and prioritize your functional requirements. That is in itself a challenge because a huge amount of information comes out of these workshops and not everything can feasibly be delivered within the project budget and scope. And you have to manage that sensitively. You have to be able to manage that in the context of the overall goals and objectives of the project. And then last, but by no means least, talking about how to finalise and sign off those functional requirements. And that is the end point of discovery at which you then move on into development phase.

I hope you find these videos useful. If you have any questions, please feel free to email me, james@digitaljuggler.com, or you can get in contact through Twitter and LinkedIn. My contact details are on the website.

Thanks very much for listening