By one measure, the US presidential primary season is off to a rough start.  In a small state, counting the ballots became a challenge.  Wasn’t technology supposed to solve the problems of past confusions?

Yet the mechanism seemingly failed—again!  How is this different from the Boeing Max 8 disaster?  In one sense it isn’t.

Disclaimer:  The only information this author has on the recent electoral IT problem is publicly available and he is not aware of anyone involved in that process that he may know personally.  This piece is only an opinion about a technology issue.

Technology Adoption Process

App developers strive to get to MVP as rapidly as possible.  Wikipedia defines a Minimum Viable Product as, “A version of a product with just enough features to satisfy early customers and provide feedback for future product development.  Gathering insights from an MVP is often less expensive than developing a product with more features, which increases costs and risk if the product fails, for example, due to incorrect assumptions.”

Speed is of the essence in software development.  Yet, a rapid time to market should not sacrifice adequate analysis and assurance the software is robustly ‘stress tested.’

Apps are moving from simple tools designed to call an independent driver of transport or order a burger.  They are now integral parts of enterprise solutions with broad implications if they fail.  This changes the fundamental project development process and benchmarks for release.  This is true for all App developers, even if their employee base is one or the development process is outsourced entirely.

Release Maturity

Most new technologies start is some’s ‘garage.’  Whether Steve Jobs’ or 3M, the processes are ad hoc and getting a so-called ‘Alpha’ product is the goal.  Those third parties who accept and test it know their risks and exposure.  Such customers would never use that release in a production environment.

Other maturity models include Technology Readiness Levels (TRLs) by NASA and the European Association of Research and Technology Organisations.[i]  At a minimum, testing must assure it is fit-for-purpose and that the product can ‘scale’ to meet the expected demand.

Technology vendors to ‘critical infrastructure’ sectors such as oil and gas often express exasperation at the sometime slow take up of new solutions.[ii]  Individuals that take excessive risks deploying new technology may literally be putting their career at risk as well as their critical processes.  Therefore, they tend to be risk averse.

There are many examples of what not to do rolling out new technology.  This month’s primary election is just the latest.  The adage, ‘no one wants to make the front page of The Wall Street Journal’ has a lot of truth to it.  Make sure you and your customer get media coverage for the right reasons.

How Do You Know Technology is Ready for Enterprise Wide Deployment?

For More Information

Please note, RRI does not endorse or advocate the links to other third-party materials.  They are provided for education and entertainment only.

For more information on Cross Cultural Engagement, check out our Cross Cultural Serious Game

You can contact the author as well.

End Notes

[i]  https://en.wikipedia.org/wiki/Technology_readiness_level

[ii]  https://therrinstitute.com/critical-infrastructure-sectors/