5 July 2011

Minimally Viable... Project?

As I'm checking through my news feed, I ran across this great post from 37signals about what happens to user experience in a minimally viable product. This started me thinking... what would constitute a minimally viable project? Before we dig into that idea, what is a minimally viable product?
MVP, if you aren’t familiar, is an idea from the Lean Startup scene. In a nutshell, it means to do as little as possible so you can learn if you did the right thing or not. 
The first thing that comes to my mind about running a minimally viable project (I'll refer to it as MVP from here on out, so don't confuse it with MVP from the quote) is scarcity. This isn't with a 'do more with less' management BS, but just an acknowledgement that the resources and ideas you do have are precious and should in no way be taken for granted. Lean Startups usually have very little money, and thus very little time, to create their product and get just enough customers to survive until the next round of funding comes in or until you get enough paying customers to sustain your company.

Sometimes projects start out with a surplus of resources, all of which are the wrong kind. When you're trying to figure out what needs to be done, projects often suffer from a too many hands in the cookie jar syndrome. The opening in the jar, our project funnel, can only support so many people reaching into it at one time before fighting begins. In this situation, cookies may be in plentiful supply, if the jar is large enough, but cookie access is scarce. The more hands trying to access, the more scarce will be cookies outside the jar due to hands getting in each other's way.

Starting an MVP requires having the minimum number of right resources to get the project off the ground. Any more or less of the wrong kind of resource and you are failing either the 'minimum' or the 'viable' part.

Another part of the Lean Startup process is a focus on using the tools you have available. Because of funding restraints, these usually end up being free, open-source software that the startup can acquire with little to no cost and can modify in any way they please. You don't necessarily have the tool that is perfect for just what you're trying to build, but you have tools that are good enough to get the job done now.

How many times have we waiting around to start a project because some piece of infrastructure or specific resources were unavailable? How frustrated did that make you? Yes, as I pointed out in the prior section, resource scarcity is a reality, but when you're in an MVP situation, you do not let yourself be hindered by the lack of that exactly perfect resource. You do without, knowing that at some point you will likely have to scrap much of what you've done anyway. Why would you end up tossing what you've done away? That's where we come to point #3 in the Lean startup.

Lean startups are all about iteration. The idea is to release quickly and often, get your customer's feedback on what you've done and then make it better at such a rapid pace that before they can get bored with what you're doing and move on. You constantly engage them with just enough progress that they stick around.

One of the things that often frustrates me is walking into a requirements review session knowing that its going to be two weeks until I see the revised document from the analyst. Yes, watching someone who is not computer savvy (or using a bad requirements management tool) attempt to update a document in real time during a meeting can be the definition of painful. When you're with an analyst who can fly through the changes, its amazing how seeing the final revision take shape in front of your eyes changes your entire outlook on the project.

Does your organization practice MVP? Do you think its something that sounds nice but is best left to the realm of the lean startup? Let us know in the comments.

5 comments:

  1. I think this makes sense and is being used. I usually refer to this as doing just enough fqor a particular project. If time to market is important, you'll most likely do enough to get oqut to the market. But what if there are regulatory issues. More rigor probably needs to be put in place. Same would go for a system that may have life and death concerns.

    ReplyDelete
  2. Great post, Ted. MVP doesn't apply to most of the projects done by large financial organizations, like Kupe points out there are limitations associated with its usage. My organization therefore doesn't have this practice as yet. However I have seen this practice a lot in the product based development, esp with usage of cloud technologies and platforms the MVP approach is gaining traction.

    ReplyDelete
  3. Something I've wondered about for a while, but because I only did a short assignment in a finance organization (and that on the sales side), I never had a chance to ask...

    Given that the regulations themselves are not necessarily the question, but how to integrate those regulations into the organization, why has no one ever put together a prebuilt package of requirements for new financial regulations? i'm not talking about necessarily system requirements, more business requirements. true, financial organizations (at least large ones) usually have teams that comb the regulations and produce a requirements list, but it seems as if it might be easier to buy them in a bundle and apply those to a system. if the source is trusted enough, why not? i assume part of this is a risk of the source not being trusted enough. thoughts?

    ReplyDelete
  4. I really LOVE the idea of Minimum Viable Project. It is too easy to sit back and wait for "everything you need" and never actually do the project until months out. Identifying your team's strengths and resources and adjusting the priorities helps you get the project moving, which is clearly satisfying to everyone involved. Great idea!

    ReplyDelete
  5. @Ted, a bunch of analysts at www.modernanalyst.com tried to spec out a template for a banking system spec, but it withered away. I think two problems; (1) no-one is paying for the work, and (2) legacy issues drive the bulk of requirements (eg interfaces, legacy systems, org structure, UX standards, etc.)

    ReplyDelete

Search This Blog