When enterprise software projects fail, it is usually not from a lack of skilled developers, detailed requirements or meticulous controls. They fail when development efforts are not focused on achieving clearly defined solutions to tangible business challenges. They fail when the internal stakeholders they purport to benefit feel no connection to or ownership of the outcome. They fail when a solution takes so long to deliver that the business challenges it was conceived to address have been eclipsed by more pressing concerns.
In the face of these challenges, many organizations are maximizing their potential for project success by embracing the concept of minimum viable product or MVP.
To illustrate the benefits of adopting a minimum viable product delivery approach, consider for a moment a real-world analogy. Anyone who has eaten at a fast food restaurant more than once has become intimately familiar with the following simple process:
Even during the busiest lunch rush, your order is treated as a standalone product, which must be completed and delivered as quickly as possible. To emphasize the point of this analogy, let’s consider an alternative approach to managing the “fast food” experience:
This revised approach to meal preparation is preferable to the previous alternative, no? All stakeholder requirements were taken into consideration and, within practical reason, incorporated into the final design of the order. All of the deliverables arrived in one release, so no stakeholder felt less valued than the others. All of the designs confirmed prior to order processing are readily discernible in the delivered product. Admittedly, the fries are now cold and congealed. The melted ice has left the drinks watery and flat. Every burger is plain, since the level of effort for customization proved too complex, and pressure to meet the time expectations forced the decision to leave final product configuration to the end customers. But the order was delivered on time and on budget. Perhaps this is what success looks like, and this business will thrive. Perhaps not.
If the process improvement of the second scenario sounds ridiculous, then why does it sound so much like the last IT project your company completed? If the more familiar fast food workflow feels oversimplified, at least consider some key points it illustrates:
We have all heard the expression “less is more”, but why should that make any sense? No one ever went to a final job interview and approached the question of salary requirements with a “Less is more!” attitude. So why would you want a project to consist of the narrowest possible scope your team is capable of delivering successfully?
The answer is focus. Focus matters. Unless a project directs enough of its resources into solving one really big issue, it runs the risk of nibbling around the edges of many pain points without making much progress at addressing any of them. To gauge whether your project has sufficient focus, here is a quick test:
Defining project focus this narrowly (minimally) requires organizational discipline that must be learned and reenforced. Analysts must identify the single most critical challenge the business currently faces. Architects must define a solution that addresses that challenge as narrowly as possible. Senior Leadership must commit sufficient resources to implementing that solution as quickly as possible. Managers must prevent those resources from being diverted to other, less critical business priorities, until after the solution has been successfully implemented.
So the scope of our initiative has now been minimized, but what makes it a product?
Apple founder Steve Jobs is widely credited with popularizing the phrase “Real artists ship.” Stinging from a two-year delay in releasing the first incarnation of the Macintosh computer, and painfully aware of the rapidly growing market share of IBM-compatible Microsoft solutions, Jobs arrived at a conclusion that would drive much of the rest of his career: until you place something in your customers’ hands that helps them do something, get something, or learn something, you do not have a product. You have a hobby.
Techno-partisans have quarreled for decades about whether or not Steve Jobs was correct in his belief that Microsoft was failing to turn out products as elegant or innovative as the solutions that Apple was developing. Jobs was forced to accept, however, that Microsoft was winning the war for control of desktop computing. They were winning in large part because they were more available.
As Jobs learned, for any solution to add value to an organization, it needs to ship. Waiting months to address the company’s most critical issue because the proposed solution is engineered to address a smorgasbord of less important concerns is a recipe for turning a bad problem into a worse problem. Delivering a targeted solution to resolve even a small portion of the company’s most pressing business challenge generates benefits well beyond the incremental improvements scoped for delivery.
Viability is the element of MVP that reconciles the sometimes competing desires to create product value on the one hand, and to minimize effort, cost, and time on the other. In its simplest sense, a product is “viable” when it meets a customer’s need to do, get, or learn something, without relying on a feature or function not yet developed. The product as a whole stands on its own, delivering value even in the absence of features not yet developed. The challenge for the business analyst and architect in defining a minimally viable product is to identify the point at which a collection of features is viable, but removing anything from that collection would leave the entire solution no longer viable. This is a point of equilibrium that can be reached from either a top-down or bottom-up approach.
The business analyst and architect evaluate proposed solution A. Either may challenge the proposal, saying, “That is not a product, because it’s not viable. In order for that to be viable it must have Feature B. Feature B is critical to having the solution work at all.” The question of viability may be either technical (the solution will break) or functional (the solution has no business value). In this case, feature B is added, and the solution is now viable. There may be other features that would be nice to have, but because the solution is now viable, they are not part of the MVP.
Might there be time and budget to add desirable, closely related features? Yes, and often companies choose to build toward a “more-than viable product” solution. However, this introduces two common risks. First, recall that one of the key benefits of rapid delivery is that lessons learned from one product implementation are used to improve the design and development of the next. That nice-to-have feature that we are choosing to add onto the MVP of today’s project might have benefited by the lessons we haven’t yet learned. The other risk associated with exceeding MVP is common experience of a more-than viable product rapidly evolving into a well, while we’re at it product, before sliding into a wait, who asked for that product?
Working toward MVP from the top-down presents a similar process in reverse. Business stakeholders request a large-scale solution. If implemented as planned, the entire solution will constitute a viable product. On down side, there is nothing minimal about it. The proposal is to implement the entire solution in a single release, nothing will be delivered until everything is complete, and the effort may consume more than a year.
The Business Analyst and Architect work their way through every feature and function of the proposed solution, asking two simple questions:
Any feature that is neither critical as a business priority nor essential for viability is removed from scope. At this point, the project is made up entirely of features that are either directly relevant to the stated focus of the project or necessary for solution viability (or both).
Sometimes, less really is more. The benefits of establishing and practicing a disciplined minimum viable product approach to development are numerous:
With so much to recommend it, one wonders why the rapid development and delivery of minimum viable product solutions remains more the exception than the rule in so many organizations. The truth is that most companies operate under long-standing organizational structures and behaviors, which raise barriers to a lean development methodology. Rather than question the legitimacy of these obstacles, practitioners need to demonstrate an understanding of these organizational barriers to formulate a compelling argument for change. Even apart from institutional roadblocks, support for a rapid development methodology requires the availability of certain prerequisites. These are topics that merit greater attention, and both will be the subject of further exploration in a later post.