When you’re planning a project or designing products, you know that you don’t need to produce any early mockups because you, and possibly many of the team, can see the vision already. You don’t need to see anything tangible before it’s due because you believe in what it is going to look like, way before you can hold it in your hands. Seeing as you’ve got so much ground to cover before then, its not worth delivering a symbolic item so early.
However, not everyone shares this same vision so clearly, and there can be so many advantages to producing and making available early beta and even alpha versions because tangible articles, even if they’re a long way from the final embodiment of perfection, are sometimes the best way to avoid very common obstacles.
Here are four that spring to mind immediately…
- Your customers may not be as experienced at projecting the vision within their own heads, and it may be difficult for them to answer your questions honestly when you are trying to probe for requirements. Once you give them a toy to play with, they can very rapidly tell you what’s wrong with it and what they like about it. The more well-defined the “future reality” you present them with, the more well-defined they will express their actual requirements (rather than mere preconceptions).
- There are a lot of people involved in a project, and if any single person sees a slightly different view of the vision, they may tend to go off on false tangents. Within the project team this is usually a minor issue, because control is strict enough to avoid inadvertant diversions. However, because projects rarely deliver in isolation, but deliver to other parts of the business, or often concurrently with other projects, it could be easy for other stakeholders to see the future differently. Unless, that is, you can give them a clear example of what you will deliver.
- Even if there are pre-requisites to the final deliverables and logistical hurdles to mass-producing them as production-ready articles, you ARE going to have to produce them at some time. As long as the effort of hacking together a mock-up does not delay other areas unduly, its unlikely to be wasted time. Of course you have to be progmatic about which parts are realistic, and you should quality control the tests that other people run so that the final version also meets all their criteria. Some people might say “but we don’t want some non-technical business manager sticking their oar in and asking if we can produce it in the corporate shade of blue”, but they will say that whenever they first see it, and its better to get those questions out in the open way before pilot.
- Sometimes it can be hard to deliver anything, so getting into the swing of it with prototypes is a great way of ironing out all sorts of wrinkles in the host organisation without letting them every get close to a critical path. Also, its unrealistic for a project to pretend that the business “as usual” around them will live suspended in a homeostatic bubble of rigidity. Change happens, and if the people delivering more change cannot keep in step with the changing world around them during the project, then they are going to have severe difficulty delivering anything at the end that the customer feels was worthy of the effort.
Sometime is might be clear that there is direct value to planning in early releases for people to look at. Even when there is not, however, bear in mind that encouraging people to lay their hands on alpha and beta versions of _their_ key receivables can be a mitigating tactic for so many potential risks that lurk around your project waiting for the opportunity to spring