Mike Masciandaro is, a veteran business intelligence practitioner who recently retired from an illustrious career at Dow Chemical and before that, Rohm & Haas, which Dow acquired in 2009. Mike served as director of BI for both companies for nearly 20 years. During that time, Mike has seen and done just about everything there is to do in the world of BI, data, and analytics. He is now intent on sharing his hard-won knowledge with others.

Key Findings:

• BI teams can benefit from CRM systems
• Getting to saturation point of adoption takes ten times as long as it takes to build something new. Build it in months, adopt it in years
• Perception of delivery speed changes when you press the flesh and talk to customers
• Humility is important, scale out small, individual successes
• Data quality is in the eye of the beholder – people don’t want to hear bad news so they question the quality. 
• Tell them what they know, then tell them what they don’t know
• Keep things simple at first – stick to extremely small wins and be customer-centric

This is an excerpt from the second podcast with Wayne Eckerson and Mike Masciandaro

Wayne: We all know that a BI team lives and breathes on the rate of adoption of its reports and applications. From your 20 years of experience in the field, what are the keys to BI adoption?

Mike: My whole team would tell you that adoption has always been near and dear to my heart. Pretty early on it became apparent to me that we build a lot of things in business intelligence or data warehousing areas. We build reports, I call them “products”, but building is rarely what’s going to drive success in your organization. You have to work on getting the business to use the things that you build. Creating that stuff is great, but it’s certainly not enough, and there’s a whole set of things that you need to do to get things adopted, and it’s a whole subtopic of itself that I’m really happy to be talking to you about today.

Wayne: What are the top three keys to adoption?

Mike: Once you create these things, you need to promote them. It’s not one of these things that you create and they will come. You need to promote it, communicate it, train people on the tools, but we went after more of usability and the UX experience to try to make things more intuitive.

If tools require a lot of training, it’s very hard to keep up with the adoption curve for that because your user base is turning over quite a bit as you have new people in your organization. So, this whole thing about communication is very important. Usability gets in there, but if you’re not measuring what it is that you’re getting out of that…

So, what we did was we had a very robust system of knowing what is being used, what reports, who is using it, when did they use it, what are the trends of the usage of each one of the tools – I call them tools. I also call them products. What I like to think is that we’re doing business intelligence on our business intelligence. So our BI program is being measured through the same kind of techniques that we use to define the business. For example, we’ll target the top users because we know who they are, the top 10, because they’re the ones that are using the tools, so they know the most about what’s valuable and what’s not valuable for them. We’ll use that to drive our iteration. People call that agile development. I call it iterative development, but I use it in that way. I think that’s important.

Basically, we develop a whole customer intelligence model around that, so we know who the users are, what the hot reports are and I could tell you the top 10 reports – I was calling them the “power rankings” – and what is it about those things that make it tick. But that’s the big piece of it. Business engagement is very important, and those are the top items there that I would point to.

Wayne: Once you’ve put something out there, what do you do to communicate that it’s there and ensure adoption?

Mike: We have multiple channels that will go to market here, and in the last podcast we talked about the business analysts that we engage with. So we have multiple channels that go out there.

We have a business group called the Inside Explorer Network that is over a thousand business analysts that we can promote to. In the portfolio, we have analysts talk about the areas that are hot for the business. Then we have business IT that is set up in our organization, and these are IT people that reach out to the businesses directly at a high level.

We use that channel, but mostly what we do aside from all of them is go direct, both from bottoms-up through some of those methods, but also top-down by reaching out to the high level folks in the business. And we market to them directly and try to really explain how the tool is going to add value. It’s a full spread approach.

We have many CRM systems that we use. It’s sort of poor man’s CRM where we keep contacts and what those discussions were with every business person that we meet with. So if you’re going to go visit with somebody you could know how many times we talked to them, what we talked about, and when we talked about it, so that we’re being intelligent about how we approach the businesses.

Wayne: I have never heard of a BI team using a CRM to track their user engagement. That’s pretty interesting. What kind of information did you glean from that and how did that change how you interact with users?

Mike: I’m surprised we’ve never talked about that one, Wayne. We’ve talked about a lot of things in our interactions. CRM systems very rarely get used like they should be getting used, even in the business, and my theory behind that is CRM systems are too difficult to use. It’s a very form-based thing, and it takes you a long time to make the interaction.

We used a very simple share point site where we validated who the users were through the active directory. But then it was basically a text-based. Some things would be locked in there like the date that you entered, who entered the record, who the person was, and you would just put down a couple of sentences about what the interaction was about.

You get a lot out of that because you become really intelligent about your customer base. Now, if you have a very, very small customer base, if you only have 50 people in your customer base, you don’t have to get real formal and structured about this. You probably know these people and know their spouses and their birthday, but when you’re dealing with multiple hundreds and thousands, we had over 12,000 users in the system, you have to get a little bit smarter about it.

So we would have discussions, understand what people were doing, and learn what people used and what they didn’t. When we talked to a leader, if they felt that there was something important, we could tell them the stuff that was being used in their organization and where it wasn’t being used and enlist their help to try to open up doors in some areas of their organization that was lacking. Most of all, it allows you to really sound intelligent.

If you walk into somebody who you haven’t seen in six months, and then you say, ‘Oh, yeah, we were talking last April and it was about this,’ and ‘How did that work out?’ Or better yet if somebody else in your organization has met with this person, you could talk to that person ahead of time and arm yourself with information so that when you have the 30-minute time slice with this important person, you could bring the right information and focus on what’s important.

Wayne: Did you use this primarily to support your face-to-face meetings or phone calls with top users or was this for tracking interactions with everybody?

Mike: We weren’t being overly prescriptive with this. Naturally you need to cut it off at some point.

Some people in the organization would start logging a discussion around a helpdesk topic, and we learned to draw the line and say. If the person has to get their password reset or all that, we don’t need that in the system. That’s just clutter.

So we ratchet it up a little higher than that. We basically record that you’ve met with the user and there was something that was either a request of theirs, something that was on their mind from the perspective of running their business or functions, or something that was a hot topic that maybe they didn’t know how to address. Maybe it was lacking in our product portfolio – that sort of thing.

Wayne: You mentioned training and that the best training doesn’t happen because the tools are so intuitive, but what kind of training do you provide or support to ensure adoption?

Mike: We made a major transition between having training, which was abstract from the report. What I mean by that is screenshots and PowerPoint presentations. We still have some of that here and there. We were actually heading towards using some technologies that can give you an overlay to an actual report. So part of the report design has an overlay that you can turn on that is a little bit of a tutorial.

You’ve probably seen these things. It’s been around many years, but it really has never been done well. So we can detect the first time you enter a report and start prompting people, saying, ‘We could show you around.’ You could skip by it or, if you want, you can come back to it. It’s not so much on how to use the tool but what the context that others are using the tool in. As in, ‘Why does this reporter or analytic exist? What is it helping people do?’

We could probably have a whole segment here on business interaction. It was my belief that the best way that users can learn a tool is to reach out to other users who are using that report and let them learn from them.

Wayne: Successful companies engage with the business. What are the primary ways that you engage with the business?

Mike: There’s probably at least four ways we do that.

The most rudimentary is a ticketing system – everybody still has a ticketing system. If you don’t, you need to get interactions and categorize them, catalog them, and mine them. There are other methods like we just spoke about like CRM systems.

We also reach out to get feedback from these analysts and IT, so we do some traditional surveying. Once a year we would go out there and ask questions such as, ‘Do you know what the portfolio is? Is it useful enough?’ Always give people the ability to provide textual feedback. I think you learn the most out of that.

We have regular categories that we track to see if we’re doing better to get our satisfaction numbers up. And that’s the way you have to drive it if you’re not listening to your customer base and seeing where your weaknesses are. It’s great to get testimonials which is another thing we do quite a bit – that helps drive adoption – but it’s a multipronged approach here.

Wayne: Do you have individuals on your team who are assigned to departments or business units who kind of immerse themselves in that group to understand their needs and proactively address their concerns?

Mike: Not directly on my team. In the first podcast we were talking about we talked about the analysts that I have in my organization. They are subject matter experts in some areas, and we have functional analysts who are indirectly connected to the organization. On the business side, we have business IT, and they are high-level people who have a seat at the business leaders table to understand their needs.

The good of that is you get a door open for you where you don’t have doors open, but the downside of that is that they’re very, very generic, and business leaders can’t understand the details of what we’re bringing to the table. So they don’t even know what their portfolio of reporting is. If they’re hearing a problem when they’re sitting at the table, they can’t necessarily come back and go, ‘Oh, I’ve got the thing for you. You know, we’ll sign you right up.’

Sometimes that happens and it’s a very good door-opener for us. But one thing is for sure, it ends up being like an account manager, a corporate account manager. They bring us in if they have a need that we want to follow up on. But that’s not a replacement for us going out directly. I had a small contingent of folks that were involved with value assessment, in terms of the value that we’re bringing to the business. They used these contact databases. And I’ve spent a lot of time doing it to try to build those relationships so that you can see what people are doing with the tools and how it is actually helping them.

We did value assessment after use and tried to stay away from dragging somebody through a big value assessment before, because people don’t really know how valuable some of these things are going to be. But they can articulate it a little bit better on the post side after  using it.

Wayne: Businesses these days want to go as fast as possible. How did you keep up with them?

Mike: Really good topic, especially when you’re in corporate IT. You get painted with a brush of ‘you guys are too slow. I gave you a requirement and I didn’t hear back from you for three months or six months or never.’ I took it as a personal challenge to not let that happen, and I think what I found was very, very interesting.

If you measure adoption and you look at how long it takes to build something and then how long to get full adoption in the organization, it’s very enlightening. Getting to the saturation point of adoption in an organization easily takes ten times as long as it takes to build something new, and I always found that very interesting.

People complain that you’re development cycle takes too long, but if you can shorten that development cycle from three months to two months to one month, that’s great. But the adoption cycle can take years. We’ve had reports without doing marginal analyses with 95 percent customer satisfaction. And even with a very effective report we were seeing growth and adoption years after it was put out there. That’s mainly because our organization was so big, but I found that to be a constant – that adoption curves are much, much longer than development curves.

Specifically to your question though, we want to listen to the people who are really bringing good information to us. So people build credibility. Some people ask for stuff all the time and then when you deliver it, ‘it didn’t really work out’. Our portfolio was full of stuff that we built that wasn’t getting much use. We wanted to govern that upfront. Some people nail it; some people don’t.

The perception of your speed of delivery changes when you have close customer interaction and you deliver stuff. We got to the point where things flipped around – people were saying, ‘Oh my gosh, you guys have so much content that you put out there. We have a problem of absorbing it all.’

Then the question becomes ‘How do I make sure that the content I’m putting out there is pointed at current business problems to the greatest extent possible?’ That helps to really change the perception of being slow.

Wayne: A lot of people talk about using self-service to speed delivery, essentially outsourcing development to the business. How much of that was part of your strategy?

Mike: The self-service stuff is important. I don’t think a program that doesn’t have self-service is going to be a good enough program. You could have structured reporting that is flexible, but there’s still going to be the need for having super analysts out there to hear and twist things around and self-serve.

We put our arms around that and tried to learn from that. I think self-service is a good channel for us to listen to people and their problems, especially if they’re high-credibility analysts.

The good ofself-service analytics is that the person is right there in the business. The bad of it is it’s not very scalable. They can get an answer pretty quick, but it’s not very automated or supported. Analysts don’t want to have that ball and chain around their necks forever. It was a string of pearls earlier on, but if it becomes something that is going to be more mainstream, they would rather have it in the portfolio. There’s a lot of moving pieces, but that’s how we engage the self-service analytics side.

Wayne: And how would you move an ad hoc report that some super analyst did into their production portfolio? Was there a process for that or not?

Mike: At the Inside Explorer Network many people came up and talked about their successes and then we would evaluate some of those things such as, ‘How many customers do you have? Do you really have a lot of customers? Or is it just something that was a couple of people?’

We would take something and evaluate it with some of our senior people. Sometimes people did some very unique innovative things and we tried to learn from that and help them do things better in a number of ways. These things serve as good incubators for building stuff into your portfolio.

Some of the top successes that we had were things that somebody had done somewhere else and then we were able to scale that.

Humility is important here. It doesn’t have to be thought of in your own house to drive value for the organization. We were very open about giving awards out to the top Inside Explorers and profiled them within the Inside Explorer Network to make people feel good about what they did and give them credibility in the rest of the organization.

Wayne: So, these inside explorers are the so-called super analysts that you mentioned before, the power users who are building some of the ad hoc stuff, right?

Mike: Yeah, absolutely, and they range from people who are data assemblers to people who are real business savvy people. All of them have tech skills to do data modeling at some level and some visualization work. The people who are just the assemblers of that, they were the ones that almost feel threatened by the whole process because they want to just sit there and assemble and stamp these things out.

They’re part of the network, but not our key focus in the network. The key focus in the network are the people who are real business savvy. They will be the first to tell you that once they have something that’s important and used, they want to automate that and put it into the standard reporting portfolio so that they can move on to the next things.

Wayne: Would you leverage the assemblers to help you do that or were they assembling things on nonstandard platforms? Were they your ally or were they hurting the cause?

Mike: It’s a loaded question because people end up on both sides. Sometimes these people clearly draw the battle lines for you, and they have their little operation and you’re not going to take their business and they own it and so forth. I tell those people go to town. If your organization is paying for you and you think you have a great run organization, that’s great. There’s plenty of business for me to pick up in other areas, but what ends up happening is people start looking at what you do from a centralized perspective and how you’re working with other analysts. And they’re going, ‘Jeez, why do I need this little thing over here in the corner? Can’t we sort of push together.’

I never targeted them for a bakeoff. There’s just too many open spaces to go, and there’s no reason to make this a negative thing. So if somebody was over there in some corner of the earth doing those things, God bless them.

Wayne: Did you find that you ended up taking over a lot of those systems anyway down the road?

Mike: Well, do people then knock on your door and say, ‘Hey, can you run this for us?’

Wayne: Yeah.

Mike: No. If we want to scale something out, we’ll have a project. We’ll do it, but we’re going to put it on our platform. We’re not going to just try to take over one of those things. If you think it’s important enough in your business, then invest in that one area.

Taking over little spreadmarts built on old technology in another part of the organization is not a winning strategy. You end up with too many things that are not the right architecture. If those things were going to die overall, let them just die. Was that frank enough?

Wayne: Yeah. I always say let it ride until it dies. I may have even gotten that from you. Eventually those things get so fragile and brittle that they’re willing to convert to the standard portfolio and platform because they get a hell of a lot more in return for changing,

Mike: If there’s a report that’s telling you one version of the truth and theirs is telling you a different version of the truth, ultimately we take the high ground because our stuff rolls up to the P&L and the balance sheet. And if it’s telling them a different story, a lot of the senior leaders start going, ‘Hey, I don’t want to be running something on my own that’s saying something different than the corporate system.’ That argument happens when you’re at a level of maturity with a big program. If you’re brand new program, you can’t take that attitude. It has to be a little different if you’re just starting the program.

Wayne: There are a lot of things that can undermine adoption of BI in an organization, such as performance and data quality. How do you ensure that business users trust the data in your reports?

Mike: Data quality has to do with architecture and what you’re building and modeling, but sometimes data quality ends up being in the eyes of the beholder.

If you have a tool that is telling somebody bad news, the first thing they do is question whether it’s right or not. They don’t want to hear bad news, so they question the quality even if it is right.

The opposite side of it is that if it’s good news they accept it very quickly. There’s a lot of this human side to data quality that plays into this. If I’m demoing something to a business guy, I’ll anchor on some big things. I’ll think about it as ‘Tell them what they know and then tell them what they don’t know.’

Let me give you an example. We’ll filter down onto their business over the last six months and then take a look at customers, and I’ll show them the top 10. These guys are going to know who their top 10 customers are. Once you anchor them on that, then you can start spinning the data around and showing them something they don’t know. That really helps.

You talked about performance. We’ve spent a lot of time making sure performance is great, and every click has to happen in five seconds in my shop and it’s hard. We ended up getting over 90 percent. All clicks we return in five seconds or less.

Wayne: Performance, data quality – those things you just have to do right. Are there any other gotchas like that or must-haves?

Mike: Usability is important. You want things to be easy to use so that people can begin to understand. You have to have right security around the data. I talked about speed of response. What about refresh speed? Is this real information and how close to real-time are you and what’s the right level of real-time changes versus batch updates?

Wayne: If you could start over again, how would you do things differently?

Mike: I learned so iteratively, and I think back to when we started how naïve we may have been. For a person starting a program listening to this going, ‘Oh my gosh, how do you build all that?’ my recommendation is to keep it really simple at first. Focus on embarrassingly small wins upfront. Your portfolio doesn’t have to be huge. It has to be customer-centric. You shouldn’t go off and just build architecture and say to the business guys, ‘Hey, I’ll be back in six months and it’s going to be great, trust me.’ Keep it value-generated. Get these people to continue to write checks for you because they value your service even though the initial ones are very small.

You tend to forget that. People are chasing this thing called big data and that’s great. Everybody feels like they need to do it, but if you’re not delivering some level of business value along the way, a venture capitalist is going to come back to you looking for some return at some point.

If I had to do it again, I’d say what I learned along the way is to do iterative program development and build slowly and consistently over time.

If you liked the podcast, please subscribe!