Alternatives to an MVP

In your project, you'll always need to define what you are delivering at each milestone, and at the end. This is usually part of the same conversation as defining an MVP, quick wins, and being wary of scope creep.

Of course, sometimes we need to deliver a minimum working or viable product, and we need to be aware of scope creep.

These are in the context of doing just enough due to limited time, resources or a need to prove to upper management or the client that we can deliver something of value so that they are comfortable taking us on for a larger project or releasing a next tranche of funding.

To achieve this, often we need to push back and protect the scope from add-ons.

I want to also mention the other side - when it is more sensible to accept and even chase a larger scope or commitment to deliver an additional value-add.

We can spend a lot of time debating and pushing back on delivering an additional feature, and this can be time well spent to avoid derailing the effort to deliver something of value. There are times when it's much better for your team and for you to just grab the bull by the horns and get it done.

Things may come up that are expected by others which are difficult to make a case to push back on.

It might mean shuffling priorities to find capacity to allocate someone in your team to do it, and likely personal involvement from yourself. There are cases when it's better to just be transparent with your team and explain, okay, this has come up. This is a new expectation we didn't know about. But we're not going to get this over the line without this being done. Or it could be a more positive story that by doing this as well, our team is going to have a much more impressive legacy.

This kind of document, test plan, evidence, logging functionality - whatever it might - typically isn't delivered in a project of this kind in our organization, but Jane is asking for it or Vikram suggested it. If it's just an idea or suggestion, then you can take it or leave it.

But if it's clearly an expectation by the security team, the risk team, your two up manager, it could be much better to just do it and then leave a better legacy for your project and team. And you've pushed the envelope as well. You've added something to you and your team's resume, and once it's done you'll all feel better for it.

You're going to be pleased that you created something that was a top quality product. If you have an idea of something that you think could add value to the project, not somebody else has suggested it, but it's come to you because you're the project manager, then consider it. Is it adding too much scope to your project, too much stress to your team, or is it something that you actually can do?

I'll give an example.

In a pricing project, there was an expectation that we sample check the prices before releasing to production to ensure the prices were as expected. The way we did this was to check that the new pricing as if it were applied to all new customers of the past month in the production system versus the simulated pricing engine.

Naturally this gave comfort, but it limited the scenarios that were covered.

We asked what if we could do this check on the past year of new customers? Then we asked what if we could do this check on the entire current population of customers including all quotes from the past year who did not convert into new customers.

This added a week to the testing schedule, so we did it in parallel with the usual production release process. Anomalies were found which were relatively minor, but we added these to our backlog to explain. The schedule for the release was unaffected.

Being able to report this level of rigorous check to upper management naturally impressed showing that our risk management was extremely tight, and also that the team was willing to take action going well beyond what prior testing cycles had done.

To wrap-up:

If a colleague or manager suggests something better and higher, you can put it in the backlog - but before doing so, consider 'is that possible, and what would it mean for our team and outcomes?' Or go the next step - and ask your team, if we wanted to aim high, what would be a crazy next level to aim for? Then consider 'is that actually possible without derailing our main goals?'

The act of asking these questions can inspire the team as a whole and as individuals to go after more both in their professional and personal lives.