“I love taking an idea… to a prototype and then to a product that millions of people use.”
When it comes to starting with an OSS build, I’m a big believer in the benefits of building a rapid prototype in one of the customer’s pre-production* environment.
Most suppliers approach their OSS implementation projects with the production environment firmly entrenched in their thinking as first priority. However, I believe that there is an alternate approach that may appear more indirect but has parallels with the fable of the tortoise and the hare.
Unfortunately, I’ve seen too many projects get stuck at the pre-implementation stage, primarily because stakeholders are fearful of making a decision on something they don’t feel completely comfortable with. Afterall, “the confused mind says no” and if the stakeholder can’t envisage exactly what final solution will look like then they often hold back the implementation rather than championing it.
My alternate suggestion is to not focus on production initially. Large CSPs will generally need a lab environment established before they’ll be approved (by the change management team) to launch a production service. As such, I feel that the effort in building the lab first before focussing on production has many benefits, including:
- The lab environment tends to have less change management constraints and less perceived risks for stakeholders
- The lab can be set up to be a close simulation of the customer’s production topology, as opposed to a demonstration in a vendor’s demonstration environment
- On most OSS projects, people spend too much time discussing and documenting “what if” scenarios. Many what if scenarios can often be easily ruled out through the proof of an actual build, rather than negotiating over the caveats of a theoretical build
- Implementers identify build issues in the safety of a lab environment so they can take remedial actions earlier, more safely and easily
- The customer (and implementer) can demonstrate functionality to their stakeholders faster, which is important for building momentum and support
- The lab environment becomes the perfect sandpit for customer staff to play and learn in, making them more valuable to the implementation team at an earlier stage
- Having a live working version provides the opportunity for stakeholders to become familiar, and perhaps excited, with the product
- CSPs can get a functionality view of the solution with a smaller initial outlay of time and budget [Note: production builds tend to be far more expensive than lab builds because they are generally higher spec and / or more tightly integrated]. Assuming they are impressed by the demonstrated functionality, there is then less perceived risk to proceed to the larger production investment
- I’m sure there are many other examples that you can find
* For those who aren’t familiar with the term “production environment,” large CSPs often have multiple instances of their OSS for different purposes. For example, “production” tends to be the live environment that customers are using on their network. Other environments include pre-production, lab, test, development, training, data migration and so on. The idea is that the different environments need to be isolated from each other because the data sets within them and the interfaces to them have different roles.