Over the past few months I’ve had several conversations around the topic of the Minimum Viable Product [MVP] and prototyping as though they are, in some way, fundamentally different beasts. Personally, I see one as a subset of the other and view them both as part of a necessary continuum that helps maintain alignment and reduce risk during the new product development journey. Initially, you want to be sure that you’re building the right thing. Later, you want to deliver reliable functionality that makes good on the promise. In my mind, an MVP is simply one kind of prototype that happens to be focused on customer-centric issues related to desirability and viability.
There’s been quite a lot of debate in recent years related to the need to take risks and have the courage to innovate. There is a concerted push for us to escape entrenched thinking about incremental change and take more plunges into the unknown in order to really differentiate and succeed. Coupled with this view is the idea that we need to embrace failure and, in fact, wear it as some sort of badge of honour. This seems especially popular among the budding entrepreneurial set. Of course, it doesn’t have to be that way.
“I've lived through some terrible things in my life, some of which actually happened.” – Mark Twain
I was recently involved in a research project looking at complexity in project/program management. I will briefly share my views on the subject here.
For me, complexity is a function of having many elements interacting in a multitude of ways with the level of complexity increasing exponentially with increases in either factor. By elements, I am referring to the full range of contributors – technology, people, information, processes and other enablers (eg finance).
Some elements that come to mind as especially important contributors to complexity in this context are: diverse stakeholder interests, ambiguity in objectives, geographically dispersed locations (incl. timezones, regulations etc), cultural/linguistic differences, novel technologies or solution architectures, the degree to which legacy systems are being modified or replaced, deployment scope (incl. volume and locations),
This week I thought we’d take a look at what I believe to be the seven biggest mistakes related to dealing with risk (and opportunities):
1. Ignoring it – this is the biggest mistake of all – if you do not have a process to anticipate and manage risk properly then something unexpected can cause delays, overspend or worse. There are five simple steps: Identification, Assessment, Design Response, Implement Response, Review (and adapt); ignore them at your peril.
The risk associated with developing and deploying integrated systems has many dimensions – complexity, novelty, speed, technology, social, political and others. The greater the risk the greater the need for some form of overarching governance and the adoption of risk mitigating approaches.
High levels of complexity are best addressed using a systems approach to compartmentalise the requirement and develop a modular solution architecture that minimises and clearly defines interdependencies.