IoT World Q&A: A Cisco Exec’s Take on IoT Projects

Maciej Kranz, Cisco's vice president, strategic innovation group, is on a mission to make IoT real. That quest led him to write the book “Building the Internet of Things” and, more recently, a workbook designed to complement it. Both were written for a target audience of enterprise and industrial decision-makers. “It’s funny because I work for Cisco, there’s actually very little technology in them,” Kranz said in a recent interview at IoT World.

The idea for the workbook came after Kranz received feedback from people who essentially said: “The book was good, but I still think I need help.” “And I thought: ‘OK, a consulting firm might charge you a million dollars for that,’” which, at least for many organizations, is out of reach. “So that gave me the idea for a workbook and, honestly, it was tougher to put together than I thought,” Kranz said. The goal was to create a set of step-by-step instructions. “The trick was making a workbook in a generic format that applies across industries using terms everybody would understand,” Kranz said. “It is a balance between being fluffy versus being too deep and too focused. I tried to sort of strike a balance between those so you would take this workbook and you would add a couple of steps to it that are specific to your industry.”

In the following interview, we ask Kranz about his IoT motivations, the top reasons IoT projects fail and the importance and difficulty of determining an ROI for IoT projects.

What motivates you to write about IoT?

Kranz: I’m basically on this mission, whether it’s with Cisco or independent of Cisco, to help make IoT real. Let’s make sure that every company large and small across all these industries can maximize their chances of getting started and being successful with IoT projects. For me, the technology piece is maybe 5 percent of IoT success.

I am on this mission to make this stuff real versus hype. I want to share concrete examples of what we’re talking about. This mission led me to write the book “Building the Internet of Things.” It’s a practical guide for business decision-makers. An example could be the person who runs the assembly line. My take was: It’s not only the technology, but it’s also the skill set. It’s the change management. How you build your business plan? Often people will tell you, of course: ‘That there’s nothing magical about creating a business plan.’ No, there’s not, but if you have never done it, you don’t know how to do it. And with IoT, there’s a real need to identify, clearly, the problem you are trying to solve and figure out who the people are you should have as part of your team.

Just getting the right team together is easier said than done, right?

Kranz: I can't tell you how many times we played a sort of adult supervision role. It can almost feel like a kindergarten environment when you bring in IT, OT and logistics people in one room. You can spend a couple of hours hearing why it doesn’t make sense for them to work together. And then once you have gotten past that initial ‘why not?’ you have to figure out how to harness the knowledge of various staff members, and then you get into doing the project together.

What is your take on Cisco’s research from last year that nearly three-quarters of enterprise IoT projects are failing?

Kranz: That was a bit misinterpreted. A total of 26 percent of respondents said that their IoT project was completely successful, but if you dig into the data, a majority of people are basically just in process. But then there’s also a section of people who got started but got stuck.

On that note, what are some of the top reasons why IoT projects fail?

Kranz: The number one mistake people make is focusing on developing a solution and not solving the problem.

Another common mistake is not having funding support. You might spend two years developing a solution and realize that the business never bought into it. So you’ve wasted your time. This problem can be fatal for a startup.

One more thing that can go wrong is wanting to do everything yourself, and you make the same mistakes over and over again.

Is it difficult to find organizations to share their IoT missteps so others can learn from them?

Kranz: When I was doing research for the book, it was really tough for some of the marquee names to go on the record that they’ve done an IoT project. It was like 10 times harder to find companies to mention that they screwed up somewhere. They worried it would tarnish their brand.  In chapter eight, which is about IoT challenges,  there isn’t a single name of the company because nobody wants to admit that they were wrong.

It seems like one of the most difficult things about launching an ambitious enterprise IoT project is just getting started, right?

Kranz: In most cases of IoT projects I have been involved with, in the beginning, somebody just needs to say: ‘trust me.’ The first time you try to calculate an ROI for a new IoT project, it is just your best guess. You’re probably going be wrong, but it helps to think about it. But after that you’ve done the first project, you’ve got to do a thorough analysis of ROI and figure out if you’ve done everything possible to maximize it. When you launch your next IoT project, you should not be getting money on a ‘just-trust-me’ basis. You should be getting it based on how successful your prior project was.

But some of the ROI benefits are not tangible things. Think of safety. There are cost benefits of having fewer accidents, but this isn’t always straightforward. In some cases, you might have IoT enhance the quality of a product. But ultimately, you should be able to measure your ROI very clearly because that will be the basis for you to get ‘on the journey.’ You should pick a project with a clear ROI and KPIs.

Sometimes, the ROI might be evident only after starting, right?

Kranz: That can happen. There are only two mentions of Cisco in the whole book. And one involves this project we did in Malaysia with our plants. We thought we could use IoT to optimize power consumption. And sure, we started tweaking how we run the machines and we found 20 percent savings. And now that we’ve done it, we can achieve a 30 percent savings across the plants. But we started with a hunch that we could optimize these machines with IoT.

Companies like PepsiCo have used IoT to see a 30 or 40 percent improvement in their operations. These are the kind of stats you want to see because that inspires the organization. If you go in and say: We did the first product and, in this one instance, we improved things by 30 percent.’ Great. If you go in and say: ‘Well, we think we had an impact, but we don't know exactly,’ you will not get funding for the next project.

How should organizations avoid aiming too low or too high with their first IoT project?

Kranz: One statement I give to people is: ‘Have a big vision, but have an architectural framework to support it.’  Then you can start small by picking a piece of the framework where you want to implement it. I think that’s important because if you start small without having a framework, the project can stall.

Of course, none of us have a crystal ball and figure out what that architecture looks like. You make some assumptions. I can decide, for instance: ‘I probably will want to analyze the data in real time.’ I may not be able to do it today, but I should think about somehow architecturally what that means to be processing data on the plant floor. I should probably also plan on having some service that corresponds with it.

Another pitfall is having a vague goal with IoT projects. My advice to the companies exploring IoT is to pick a horizontal slice and do it well.

One more topic is the diversity of your team. The OT person knows exactly how the plant runs but has no visibility into modern tools. The IT person doesn't have a clue about the 24-by-7 operation and what it takes to do, say, provide safety on the manufacturing floor, but they have access to useful tools.

Which goes back to theme of getting OT and IT play nice.

Kranz: There is this one scenario with a car manufacturer that swapped the heads of the OT and IT teams. It was fascinating to have their IT guy was responsible for OT. And it did wonders for them. The teams were actually working together. Their point of view changed.