BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
CIOs are told that a characteristic of an innovative IT culture is the ability to "fail fast." But what does it mean to fail fast and, more important, what is the benefit of doing so?
In this SearchCIO video interview, Senior News Writer Nicole Laskowski discusses what it means to fail fast with Richard Singerman at the recent MIT Sloan CIO Symposium. Singerman is an adjunct assistant professor at Johns Hopkins School of Medicine and the co-founder and chief innovation officer of TrustNetMD, a software company that's partnering with the Johns Hopkins School of Medicine and the Johns Hopkins Bloomberg School of Public Health to build a social learning tool for the medical community.
In part one, Singerman discusses his role as the chief innovation officer at TrustNetMD, and explains why the position isn't just about innovation.
I'm trying to collect tangible pieces of advice on how CIOs can build a culture of experimentation. 'Fail fast' and innovation are terms used so frequently, but the actual implementation is very difficult. Could you provide us with a tangible piece of advice on how CIOs can build the culture of experimentation?
Richard Singerman: I really don't like the term 'fail fast.' I don't like the term 'failure.' It's got so much laden on it. I understand the folks in Silicon Valley; they mean something different. When they're talking about failing fast, it almost seems like they're experimenting with a bunch of different things, which is what you should be able to do. So, we have an agile programming environment. We went from design to what our technology guy likes to call an MVP -- not a most valuable player, which is actually what I first thought it was, but a minimally viable product.
It's almost like building out the framework. But unlike a house, where once you put a lot of the infrastructure in place, it's not so easy to tear apart and put new stuff in, with software, it is. We built an actual working product pretty darn quickly, and then we've iterated. As opposed to a pure design phase and build phase and then a customer test phase, it's almost been bunches of loops of that.
Of course we had to think strategically in the beginning. What's going to be the broad framework for the technologies that we need to have in place to support what we want to do? But then when I saw that framework, I felt pretty confident that we could achieve the implementation.
One of the challenges in failing fast and what's important is that you find that different languages need to be in place: the business language, the clinical language, the technology language. And part of this failing fast is that maybe you didn't build the right thing the first time, so it's more experimenting – 'This is what we built because this is what you said you wanted, but now we understand this is not really what you do really want.' But by showing you at least the first iteration, we can get there quicker. So I'm much more of a mindset of the rapid cycle innovation versus the notion of failing fast.