The reality during your Discovery phase is you’ll capture hundreds of functional requirements. In some projects, it’s thousands of functional requirements, both technical and business. You’ll capture the underlying business processes as well. You have to be pragmatic now about which of these become critical delivery paths for your phase one launch, your MVP launch.
You will have an agreed project scope and set of deliverables based on what you’ve signed off with the vendor and the SI partner. So you have to be sensible. What can be feasibly delivered based on what’s in scope and the timeline within which you’re going to be delivering it?
You need to apply a set of prioritization criteria. A lot of people use MoSCoW, which is must have, should have, could have and would have. Starting from ‘Must’ will be things like compliance requirements i.e. you have to be GDPR-compliant, otherwise could get fined.
Then you work down to ‘Would’ have, which might be a distant roadmap capability that you think might be nice, but actually there’s no business case for it currently, no one else in the competitor set is doing it and few customers have ever asked for. So it’s partly vanity but also partly it’s a play to see whether that could have any benefit on the website.
MoSCoW is fine if you are very stringent in how you apply it. The danger with the MoSCoW method is it becomes subjective. Most business stakeholders will say that every single one of the requirements that they have defined is a must-have. They can’t work without them. Then you have to go through the laborious process of unpicking that and asking them, “Okay, do you currently have it? Yes, no? Does it currently work? Does it currently contribute anything to the business? Is there a business case for using it?”.
A good example is third-party tools and plug-ins. It’s common to hear, “Well, we must have this third-party tool,” yet it hasn’t been used for six months. Now that’s not a ‘Must’. If it has not been used for six months, it’s clearly not a ‘Must’. Then it can get deprioritized. That doesn’t mean remove it completely, it just means be sensible when defining what has to be delivered in your first phase to focus on what’s most valuable to your business and customers.
So you have to be crystal clear in defining what those criteria are and how you assess a requirement against them consistently so that you’re able to unpick what is essential for delivering up front versus what can come later. Or what actually you descope and say, “No, that’s not what the ecommerce project is going to deliver. If somebody wants that put in, they have to come back with a business case for it.” It might sound a bit harsh, but having that level of discipline will protect you against budget and scope creep.
The last thing that a project manager wants is an endlessly creeping scope because it then becomes much harder to tie down what the first deliverable is, what the first phase is. How can they cut up the sprints if each one of the capabilities that you thought was going to be delivered in a sprint keeps extending? It’s much better to have a carefully defined set of requirements that you can then add to a roadmap which you then have a process for reviewing and prioritizing and then discussing with your implementation partner about when you bring those into the project and how and what the additional cost is.
One of the best ways of thinking about prioritization is simply to ask yourself, can you sell online without this requirement? That should be your critical requirement path. So we come back to the compliance side of things like GDPR, basic-level accessibility, level A compliance, those things are essential. Anything where there is a law, for example the E-Privacy directive. Things that you must adhere to otherwise you could end up getting negative PR, getting fined. Even worse, directors being taken court. Those have to be the number one deliverable.
Next in priority is anything that the customer or the business is dependent upon in order to enable a transaction. So anything to do with payment gateways, anything to do with baskets, checkouts, ability to add a product to basket. If you’re stringent in your prioritization, it makes it a lot easier for the PM on your side and the PM on the implementation side to define what goes into the sprints, what to prioritize through development. And then everything else can come in future sprints or future phases.
Hopefully that has clarified the importance of prioritization and some of the techniques you can use to do that. If you have any more questions, please email me, firstname.lastname@example.org, or get in touch by LinkedIn and Twitter. And my contact details on the website.
Thanks very much for listening.