Is an MVP implementation the right approach for me and my digital project?

With the emergence of Agile as the preferred methodology for most software implementation projects in the non-profit sector, one of the more common early discussions we have with clients who are planning a digital project is now around Minimum Viable Product (MVP). Specifically, the questions we get asked focus on “what is it?”, “what does it mean in practice?”, and “is it right for me?”.

What is MVP?

Before we get in to the detail of the discussion, let’s first reflect on what MVP is meant to be, by taking the purist definition:

A minimum viable product (MVP) is a development technique in which a new product or website is developed with sufficient features to satisfy early adopters. The final, complete set of features is only designed and developed after considering feedback from the product’s initial users.

That definition is clear and valid, but it is purist and very difficult to apply in most of our projects, specifically because most of our projects involve the replacement of an existing system upon which a number of business functions and users rely. So could we simply replace “satisfy early adopters” with “prevent any degradation in service”, meaning that the new product or solution only has to enable us to do what the current solution does at the time of MVP launch?

There’s certainly an approach there which could be more widely applicable, in respect of the first half of the definition, but what about the second half, which speaks more to the purpose of the model. We have to have enough of an MVP release to enable us to assess the strengths, and weaknesses, of the solution, such that we can learn valuable lessons which will influence and impact the future releases.

Within that, the solution itself has to be flexible enough that we can adapt to the lessons we learn from MVP, not just in future releases but potentially also in retro-fitting features into the MVP implementation. What’s more, we have to be confident enough in the technology and partner to invest in the MVP release with a fair degree of uncertainty around the composition and nature (and cost) of future releases.

This is starting to sound quite challenging now, to fully understand and to put into practice.  It is though very much on trend to be promoting the model, so we need to think more specifically about how this could benefit the projects we’re initiating. Arguably then, it’s at this point that we need to put the purist definition back in the textbook and focus on the real-world benefits and disadvantages for our projects. The points below are those we discuss with our clients, in a more pragmatic vein, noting they are discussion points…!

What does it mean in practice?

Potential advantages of an MVP approach

• You may be able to define a smaller, shorter initial implementation, which will carry less risk and involve a reduced initial investment in time and resources
• You may be able to use MVP as a leader to prove that you can deliver successful projects
• You will learn a lot from the project as a whole:
  • About the tech how it works, what it’s capable of
  • About the partner
  • About yourselves, your culture, your appetite for, and attitude towards, to change
• You can identify champions and those who want to develop within your organisation
• You should get a big data (and/or content) migration hurdle out of the way (as you’re replacing your current solution)
• The scope can be adapted over time (but this comes with health warnings!)
• You’ll be able to review business processes incrementally
• You could go live with a ‘skinny’ but successful MVP and go on to build out a better informed, and de-risked, complete solution

Perceived drawbacks of the model

• Your project may be seen in some quarters as a once in a lifetime change, which will exhaust you, so it needs to be one-pass generational change and a small MVP won’t cut it.
• Your funders and senior stakeholders may be underwhelmed at the prospect of an MVP which only replaces current functionality despite them signing off a significant investment.
• You may create a bun fight for what’s in scope.
• Some stakeholders will resist and question “Will there ever be a Phase Two?”: you’ll need to give clear assurances.
• You do still need to fund and resource the full project.
• The demands you’ll place on your resources will go on for longer.
• You need to be able to make resource available to run your MVP release as your live system, plus retain a project team for Phase Two – with a particular crunch around key resources, and your project team

Suppose it doesn’t go so well, MVP extends, everyone gets tired, the money runs out…

All of these points are valid for discussion and need to be carefully considered, in your context

By analysing the points above and seeing which weigh strongest on you and your organisation, you’ll start to get a good sense of the ultimate question…

Is it right for me? Or how do I know if it’s right for me?

In light of the pro’s and con’s above, it’s important to asses them against the criteria below:

• People and the demands you’ll place on them
• Culture can your organisation cope with the nature of incremental change
• Budget can your budget be flexible and long-lasting enough
• Discipline do you and your team have the discipline to manage scope

To succeed with an MVP approach you need a clear vision of the scope of your MVP and subsequent Phases, also based on what you need when.

In the eternal love triangle of time vs scope vs budget, we find that an MVP model works best where Time is the driving factor in the initial project. This is especially effective where you have hard timelines, driven by external constraints

Consider what capacity you have to deploy workarounds after the MVP release, from both a capacity and also user buy-in perspective.

Critically consider what resources you have available to deliver multiple releases, and to transition them into new ways of working whilst working on the next release.

Finally, test out the technology partner you’re working with: is MVP a core part of their model or is it opportunistic? If they’re promoting MVP because it’s on trend as opposed ot being baked into their method then it’s best avoided.

At the end of the day of course, MVP isn’t a new and radical concept.

The principle of defining phased implementations of new technology, as opposed to “big bang” launches, has been around for decades and remains a strong option for anyone. It’s become the current trend on the back of Agile’s current pre-eminence, but you don’t have to adopt a full Agile model to benefit from some components, so maybe that’s the takeaway.

When planning your implementation, break the deliverables out into potential phases and see if that’s viable for you. Can you replace elements of your current technology landscape incrementally, maintaining business-as-usual, without degrading services, and without having to invest significant additional funds to re-work integrations through the phases.

If you can, if you can resource it, and if culturally you buy in to the concept, then consider whether it’s more beneficial for you than one big implementation, including the considerations listed in this article in your decision making.

As a final “if”; if a phased model works for you and your technology partner, you can come back round to the original question, knowing what your drivers are for a phased implementation. Consider how close you are to the MVP minimalism of launching iterations of “what you need, when” with the primary purpose of learning from each iteration and using that feedback to influence the next phase, including building out full feature sets.

By then you’ll have worked out whether you’re going for big bang or a phased approach; whether you’re going for a phased approach or an MVP model; and whether the last point is just semantics!