Transcript
Jess Carter: The power of data is undeniable, and unharnessed it's nothing but chaos.
Speaker 2: The amount of data was crazy.
Speaker 3: Can I trust it?
Speaker 4: You will waste money.
Speaker 5: Held together with duct tape.
Speaker 6: Doomed to failure.
Jess Carter: This season, we're solving problems in real time to reveal the art of the possible, making data your ally, using it to lead with confidence and clarity, helping communities and people thrive. This is Data Driven Leadership, a show by Resultant. I'm your host, Jess Carter, and on this episode of Data Driven Leadership we're taking a closer look at how you begin to think about organizational data transformations. More specifically, we're exploring what it looks like for an organization to start a data transformation project and generate real value quickly. To help you Solution on the Spot is Michael Tantrum, a national sales director at Resultant. Hey, Michael.
Michael Tantrum: Hey, Jess. It's good to meet you.
Jess Carter: Nice to meet you, too. Michael, will you tell me a little bit about your background and how you got to where you are today?
Michael Tantrum: I've always been interested in the use of data to help people make decisions, and in fact, my very first analytic database I ever created was in 1989, long before we called them data warehouses. In fact, we called them decision support systems back then. So my whole career has been helping people build and use data to make real change in how businesses are run. Sometimes that's been public sector, making changes in how healthcare is delivered to people. Sometimes that's been private sector, how to maximize profit and other factors. That's been my passion for 30 years now.
Jess Carter: That's awesome. Very cool. Well, glad to have you Solution on the Spot with me today. The scenario that we're going to be in together is we've walked into a client meeting at their request and they've said, "Hey, we've hired some really big wigs, super smart companies. They've given us all these reports on data transformation for our organization. We know we need to transform our organization, we know we need data to drive decisions, but the reports were not driving meaningful insight on how to take actions to clearly change. So while valuable, we don't know what to do, we don't know where to start." And so they've called us in and they want us to help them figure out where to begin a real meaningful data transformation.
Michael Tantrum: That's a real common problem, to take something from a theoretical, academic idea, a set of PowerPoint slides and other visualizations and actually create the real artifacts to start the project and get it going. That's a lot of decisions to be made and at Resultant we have opinions and it's based on real experience. And so the way I'd solution with that client is the first question is always, "Do you have investments you've already made, typically in technology, that we have to make use of? And if you do, we'll start there. If you don't and you've got gaps, then we can talk about reference architectures. What are the things you need to get to the start line?" And so we'll help fill in some gaps, some good tool choices and ideas like that. And then, we then say, "What does it look like to provide value?" And the way I like to do it is I take a prototype iterate approach.
We'll take the first issue, your first question from your business user, and we're going to build a prototype. And that might take a few hours, a day, something like that. And we're going to say, "Here's my prototype. Now that you can see it, let's refine it," and we'll iterate on that prototype. And it's a great way to get that first piece ready in production. It shows how does the technology work, but it also shows culturally how do the people work? How do your people, how do our people work together? Where are the knowledge gaps? Where are the skills gaps? How do you take a request, which is, "I kind of want something like this," which you can't build because it's not firm, and how do we refine that into something that says, here's a real artifact? And so prototype iterate is a great way for us to help people get to the start and then get that first step across the line.
Jess Carter: I think that's really important too because it's really easy to read these reports, and there's so much content out there about how to do these things. I think it's really hard to actually put together an implementation strategy and demonstrate value. And I think sometimes that's because if you do take that on, people are looking at the long term rollout, and to your point, to just take a piece where it's like, where's some real pain? What's one instance where you really need data driven insights, that buy-in and the insight you generate to understand how the rest of the project may play out and what kind of value they're looking for and the quick feedback about what's the quality of their data and their systems, there's so much you learn really, really quickly there. And it's not overwhelming and you don't have a C-suite sitting at the top, tapping their watch waiting to see when the whole thing is done. There's iterative value too, not just iterative work. I think that's a great idea.
Michael Tantrum: One of the biggest challenges that people find is they say, "What are we going to build?" And so when the chief data officer or the CIO says, "Right, you have permission to start this program," and then everybody says, "Okay, well, business users, what are your requirements? What is the scope?" And this is a great source of anxiety for the business units, for the consumers of our data, because they don't actually know. Now, it's not like a transaction system. If I'm going to process an invoice, there's one or two ways I can process an invoice, but if I want to analyze an invoice, there's infinite ways.
And so if you say to a business user, "How do you want to analyze this invoice?" They look at you and there's this fear in their eyes and they say, "I'm not sure I can define it because I don't know yet. I know the first question I need to solve, but I don't know the six questions that are going to come after that." And so this requirements gathering exercise is usually a huge stumbling block and a big thing that prevents people from starting. So working with business users on that is a big challenge.
Jess Carter: There's a maturity in them, right? It's kind of what you're saying too. Sometimes the design is only as good as the designer. And sometimes when they've been used to working with not enough data, not timely data, when you start to say, "Okay, give me all your requirements for a future state" that's this big thing, it's really overwhelming and they're not sure what the art of the possible is. How much can I ask for here? To your point, if you can start to understand where they're at, what their data literacy is, and we can start to show them what they could have and get a sense for their future prototype and the way that they want to mature it, you tend to see the organization mature around their data literacy too. And I think that's really exciting because you're actually sharpening the organization and their human capital too. It's not just about this cool data infrastructure, a data transformation is about the human capital who can better use that data too.
Michael Tantrum: We build these data warehouses, these analytic environments for one reason only, and that is for our end users to manage their organizations better. And all too often the IT organization loses sight of that. They see the purpose for being is to build this beautiful, elegant, technologically beautiful solution. And yet out here my business users are saying, "Hey, what about me? I need something now. If I don't have something this week or this month, I cannot respond to changing business conditions." Or maybe it's public sector. "COVID has hit and we have to do something now. I can't wait two years." And so elegance is the perfect is the enemy of the good, and the delicate balance is business or the consumers of our data say, "I need it right now," but IT says, "But you need it right." And so that's an inherent tension we always work with.
Jess Carter: Let me ask you this. So if we're playing through this, we kind of get the client to agree on a prototype. How do we give them a sense for value of the prototype or impact, if it's a good data transformation, if we're on a good path? How would you give them comfort in that and a sense of success?
Michael Tantrum: The great thing is your users, they will tell you. And so when I talk about prototype and iterate, this is a very collaborative exercise. It's what I call a conference room development. And so as I build my prototype, and particularly when I iterate my prototype, I have my user or an authorized representative of my user can approve decisions on their behalf, sit beside me. And when they see the data, I put it up on the big screen and I say, "Here's what I think you just said to me." They've drawn me a picture on a whiteboard with stick figures and lines and what have you.
I built the prototype and they look at the data and they say, "That's not quite right. Try this." And as they say try, I build it in front of them and they say, "Oh, I thought this went with this, but it doesn't seem to does it? The data doesn't give it. Try this." And so try, iterate, iterate. And then they say, "Stop. What you've got on the big screen right there, that's what I want." That's when you know you've got value because a person who's going to use it has just told you. Wrap that up, put a bow on it, move it into a productionized context, pick the next item. Already given value and we're on week one of the project.
Jess Carter: That's awesome. If you look back at this client and you say, hey, I've watched people do these for 30 years, here are the one to three things I just beg you to not do. As we think about a data transformation, as you get started, please avoid these pitfalls. What's your Michael Tantrum soapbox of "Oh, my gosh, for the love, please don't do these things"?
Michael Tantrum: Please do not insist on your business users trying to give you a complete set of everything that they're going to need in their project, because the conversation goes like this: "You want some analytics. Okay, give me a requirements document, give me a scoping document." And they will say, "I don't know what that looks like." And you say, "No document, no build." And they say, "Okay, all right, let's play hardball. You give me everything." And you say, "Well, you can't have everything." And so you lock yourselves in a room and you negotiate for three months and you come out. And in fact, in one project they came out 18 months later with this document and they said, "Right, this is what we think we need." And then they came to me and they said, "Right, we've now finally got our requirements document. Can you build this for us?"
And I took their document and I put it to one side and I said, "Right, so tell me what you want to do". And they looked at me with horror and they said, "We've just spent 18 months doing that." And I said, "Yes. And I guarantee that what we build will not look like that, because what you need today is what you need today, not what you thought you needed academically, theoretically, 18 months ago." So please don't try and define upfront everything you need, because I tell you this, there is an axiom of analytics. Your users don't know what they don't know and they will ask for changes and you do need to be able to respond to changes, irrespective of how well you have scoped the project.
Jess Carter: You've already said, don't have a siloed IT department run the initiative, right? It's got to be a collaborative initiative that is driven by business outcomes. Is that what I'm hearing you say?
Michael Tantrum: Absolutely. And a traditional IT project, particularly when it relates to analytics, is a very contentious exercise. Your users ask, IT builds, you come back six, 12 months later and you say, "Here you go." They look at you and they say, "Who are you? All right, let me look at it. Okay, I remember telling you about this. Do I like it or not?" So it's very much I ask, you do, do we accept? Not very conducive to good relationships and all it creates is this tension on the business side saying, "Every time I ask, you guys are too slow. You never give me what I want." If we turn it into what we've been talking about, it becomes collaboration. Now we're on the same side of the table, both looking at the problem together, not looking across the table at each other saying, "You're the reason I can't do my job."
Jess Carter: So try to avoid the transactional nature that these can kind of feel like. There are moments on a data transformation project that are really exciting and garner a lot of celebration and emotional excitement. And there are probably moments throughout a data transformation that are highly disappointing, frustrating, discouraging. If I'm a potential client, can you walk me through what you would perceive as preparing my organization for some emotional intelligence around what are the seasons of this rollout that are probably going to be difficult, and what are some seasons that are probably going to be pretty exciting?
Michael Tantrum: The excitement is always when you are able to achieve insights that you had an instinct with there. If you're a good business manager, you kind of know what works and what doesn't. If you're a commercial property manager, you know what makes my property work well or not, or if I'm a public health expert, I know works well. But to suddenly have data say, yeah, your instincts were right and we can actually do this, and now I have justification for why my instincts were good, everyone gets very excited about that. The downside is what happens when we can't do it? And what happens, we get into the project and we just realize the data is not there? We thought we might have access to data and it's not there. Maybe there's security issues of getting access to it. Maybe the data quality is so terrible we just can't draw insights.
And that can be really disappointing, particularly if you take a traditional approach to a project because you find out at the 11th hour, and it's very expensive and very traumatic. And so again, I keep coming back to this idea of prototype iterate. If I'm going to fail, I want to fail fast. I don't want to build this great sense of anticipation to let you down because that just reinforces the problems we just talked about. "IT really can't deliver what I need. See, they just proved it."
Jess Carter: That makes a lot of sense. And the other element here I think is we tend to be the builders or the supporters of some of this collaboratively with our client. I think understanding that, that any company that promises that you'll have these amazing insights who hasn't looked at your data yet, there's some smoke and mirrors going on. We don't know until we get into the prototyping. And to your point, to fail fast is it's a lower sunk cost if we find out that the data isn't there, that the quality isn't there, that it's not statistically significant to drive outcomes or rely on for key data driven decisions. And we can pivot more quickly so you're getting more value out of the same cost and length of engagement because you're learning more quickly how to pivot towards the most valuable things that we can do.
Michael Tantrum: And the failures don't become expensive mistakes, they become a learning opportunity to inform how to do it better.
Jess Carter: Yeah. As we tend to help build some of this and create the skeletal structure and the human capital knowledge to maintain it, walking away after the infrastructure's there, do you perceive from clients that you've had over the years that it's pretty easy to maintain a data driven organization or data transformation kind of post transformation, or are there some key areas that make sense to pay attention to?
Michael Tantrum: I think a lot of people, they focus on the technology and they forget the people side. A lot of people have come into analytics from a very traditional viewpoint. And a modern approach to analytics requires agility, it requires flexibility, it requires blurring a lot of the traditional roles. In the past, I was a data engineer, I was a business analyst, I was a technical writer. Now, in a modern world, we blur the relationships. As a data engineer, I might have to talk to my users. As a business analyst, I might have to get involved in some of the technical aspects. And so for people who embrace the change, this is great. The world moves on, they're excited about the modern approach to analytics. For those people who say, "No, my career is a business analyst. I trained as a business analyst, that's all I want to do," those people are very threatened by this. And so how you manage the people aspect is just as important as how you manage the technical aspect.
Jess Carter: That's amazing. I think you get an A plus for Solution on the Spot, so thank you for your time. So as you heard, the conversation between me and Michael Tantrum relates to this deep dive conversation we're going to hear next. The two experts we're going to hear from are Dave Haas, a business development executive at Resultant, and Caterina Luppi, the chief information officer at DC Bar. In their conversation, she's going to share some insights on the organization's data transformation journey. You'll hear how she justified needing it, how they planned for success and how they overcame obstacles during implementation.
Dave Haas: Let's talk a little bit about the data transformation and data modernization journey that you're taking DC Bar on. And I guess the first place to start is maybe talk about some of the challenges that precipitated the data transformation and data modernization journey.
Caterina Luppi: Bar had, the challenges are pretty common to most associations. We have a limited set of customers, our members, in case, attorneys, but we have this very wide variety of business lines. And each of these business lines, if they were their own business, would be using a business specific tool. Because if you publish something, you use publishing tools. If you do [inaudible 00:17:49] legal education, you do a learning management system, or an event management software and so on and so forth. But because we are all part of the same association and we are trying to do what we do effectively, efficiently, at least financially, we tend to use a single unified software that is called an association management system. So this is sort of a Swiss Army knife style application that unifies all the most common function of the association in one tool.
The problem is that if you ever tried using a Swiss Army knife, they can do in an emergency if you're camping, but it's not the tool you want to use every day, especially if you care for your fingers. It's not the ideal thing to use every day. And yes, the association management system do a good job for most of the associations if they're small or their businesses are simple. But once association become to be a little more complex in their businesses or larger, the various business lines start to reach the limit on what this association management software, this Swiss Army knife can do, and therefore they start building ancillary applications around it, they have new system around it. So this ancillary application need to integrate with the association management software and with each other, resulting in a intricate and fragile web of APIs, data transformation, intermediate data tables, batch processes and so on and so forth.
And this web grows organically over time without really having a final picture and a long-term plan. This means that in the moment in which one of these systems need to be replaced, upgraded, changed, because technology changes, this operation become extremely expensive and disruptive. When I joined two and a half years ago the DC Bar, the organization was actually reeling from one of these projects. They had recently replaced the AMS and that project did not go well. It created a major disruption to the staff and to the members and for four weeks we couldn't collect revenues, which was pretty horrible. The first task was to actually make sure that the operations were stabilized, but in the long term, my goal and really my mandate from my CEO was to ensure that the organization would never go through something that traumatic ever again. And that's why we started thinking about substantially changing the way our system architecture was built and we embarked on the data transformation journey.
Dave Haas: It's always good to have direction from the top, but I know a big part of these things is the organizational business support. How did you rally people around this and sell it? Because it's a huge change, as you said.
Caterina Luppi: It is a huge change. When I joined the organization, I spoke with a lot of people and then I circled back to the CEO during the interview. And my first comment was like, "Wow, the staff has IT PTSD." So I was dealing with a lot of people who had been shocked by the experience of working on one of these large IT disasters, IT project. I had to kind of turn them around 180. Back to the Swiss Army knife example, a chef would not use a Swiss Army knife to cut meat in their kitchen every day, so we cannot expect our staff to use tools that are not good for them, so that was one of the things. And once they understood that I had that very clear in mind, that I was not planning to push them through such a horrible experience again, things started getting much better, the conversation was much better.
So that was one thing. The second one is that we needed to... Our goal is actually to have our members have a positive online experience. Our website, and to a point we're still working to that, looked like something that was built in the early 2000s. It was not the kind of online experience we wanted to give to our members because everybody's used to modern e-commerce, modern catalogs, modern rich experience from the point of view of interactions online. And also we wanted to be able to report on all the activities of our members, all the touchpoints that they have with the organization.
So when they renew their license, when they buy one of our publications, when they participate to our events, and when they volunteer with our pro bono center or donate to our pro bono center. And then the last thing, which is a actually probably long-term goal is we need to increase our agility. Because of that intricate web of integration replacing any of our applications, especially if it's the association management software has huge ripple effect on the operations of the organization that can cripple it, as actually had happened.
Or even when the process is successful, just a huge [inaudible 00:22:56] in resources because the year in which we decide to replace the association management software, nothing else really happened. So that's why we envision the solution for this problem, the goal is [inaudible 00:23:09] and it's part of our data transformation, going from a system-centric architecture, where the association management software is the system of record and then we have all the ancillary system integrating with each other and with the AMS. Going from that system to a data-centric architecture when we have a dataset, a data warehouse and a data hub that is API enabled and is at the center of the architecture, and all the applications including the AMS that before was the center was the heart and now is actually one of the peers association going around the dataset. Our dataset, as I said before, we have to keep the data since 1972, so that would never change.
Our dataset, it is immutable, always stays there. But yes, the different application change. So we maintain the data in this unified integrated record of our members, and all the association will talk to it through APIs. So that's where we are, the journey, that's our final destination in our journey. And we did not sell this as, "Oh, this is going to be ready, this is going to be fine. This is going to be just a year project." This is a multi-year transformation project and everybody in the organization was involved, was welcome to join, was welcome to ask questions.
As I said before, people had PTSD and therefore the anxiety in the room was palpable. Sometimes you'll feel it, it was palpable. But at the end everybody understood that this is an investment the organization is doing for the future. And this was also how it was presented to the board and they understood that it's a lofty goal, but they appreciated the fact that we are breaking it in little chunks and we have a very much down to earth approach on how to get there. So that's how we worked it.
Dave Haas: Well, you've done a really good job, I think, of painting out what the long-term success looked like. Did you have any near-term success points that you put into place? How did you take the project and say, okay, a win, one month out, two months out, three months out, how did you divvy that out and what did those look like?
Caterina Luppi: For this process, first of all, we had some urgent matters. For instance, we had a cold fusion website that was actually dangerous from the point of view of the risk because it couldn't be patched. There was a risk to continue maintaining it. So we had some pretty obvious results out there. They were almost at the sides of this project, because having a new website was not necessarily in the core of the system. But it became very evident we need a new website no matter what because we needed to have a modern website, a modern content management system that could actually interact with this data-centric structure. But that was something that our board noticed immediately.
Another thing, we replaced our e-commerce, and also very visible results right away. So we decided to alternate projects that have very public visibility with projects that are instead very much internal, like setting up the data hub, setting up the warehouse. The members will never see the warehouse, they don't care about it. It's just a tool to get to the goal. But by alternating something very visible with something that is very technical, we could provide these intermediate steps that gave the impression we were proceeding. If we had done all the first set, like the data warehouse and the data hub initially, we would've spent a lot of money, but with very few visible results for the board and the members and the conversation would've been different at this point, I think.
Dave Haas: Obviously you have a bright and talented team. How did you go about finding out where the holes were and where you needed help and where you didn't need help and you could do it all yourselves?
Caterina Luppi: Yeah, after you have this kind of brainchild of a new architecture, you also realize that it's not easy. Going from an application-centric to a data-centric architecture has never been done for an association. Despite the fact that we have some very good business analysts in my team, none of us had the experience that we needed to build a data warehouse and a data hub from scratch. Also, our resources are limited and we wanted to make sure we don't make costly mistakes going forward so we're trying to be careful with how we spend the money. So we needed a partner that would guide us in the process, take over some of the heavy lifting and kind of point out the pitfalls, the landmines or [inaudible 00:27:53] say, "Ah, you shouldn't do this this way, you should do it the other way." One thing that I wanted to make sure that in this process was that my team was an integral part of the process, not just a spectator, not just a user of the finished product.
Dave Haas: At a high level, how is this going to transform the business?
Caterina Luppi: I often talk to other CIOs of other associations and we all have the same challenges. But most of the CIOs that I talk to are focusing on the issue of reporting across all the activities in the various business lines, not necessarily on that aspect of architecture, resilience and agility that I mentioned before. Indeed, there are many companies, there are several companies that has a product, that have business intelligence tools for association. So they have already all the integration down with the most common association management software, learning management systems and so on. So they consolidate the data and they make pretty dashboards and stuff like that.
But of course, unless one changes the underlying architecture of the systems these BI tools, they end up being yet another of these ancillary application around the system-centric environment with the association management software at the center and they don't really solve the problem in the long term. So next time we go to replace the association management software, we just have another tool, another ancillary application that needs to be reintegrated with the new association management system. So I hope that the DC Bar will be able to start a new kind of technology in the association wall, will acquire the expertise needed to facilitate the process in other organizations.
Dave Haas: That's amazing. Thank you. Let's talk about the takeaways. Tell us about the takeaways from this journey at a high level. Talk about some of the big things that you've learned.
Caterina Luppi: The journey is still long, so I'm pretty sure that if we have this conversation in a year time, we'll probably have a different or maybe longer list of takeaways. But if you are thinking about any transformation project or decide, beware that it needs to be rooted in pain, and by this mean that you need to address a problem, make someone's job easier, find what a pain point and trying to resolve it. Because an argument like, "Oh, this structure is more elegant," or, "This will make IT's life easier," or, "The disaster recovery will be easier if we do it this way," is not an argument that will fly with any board or any staff group. You have to address the pain point of the organization on the business side. The second to me is always remember to do no harm. As I said before, we are effectively taking apart our association management system, something that has served, not very well, but has served so far the association, by replacing the various function that currently fulfills with specific best of breed applications.
In this process, we must ensure that our data remains available and reliable and there are no disruptions of service. So in the moment in which I'm forced to say, "Well, it has to get worse before it gets better," I would've lost the trust of all the staff, all the members, and I won't be given a second chance. So I have to be really, really careful of do no harm. The third takeaway, I think, is watch your language, and I'm not talking about four-letter words here, although they might fly now and then, but in the privacy of our server rooms. So when I talk about is I refused to talk about data transformation internally. I mean, this of course is a conversation with IT people, with a IT company.
But if I started talking about data transformation in any of the meetings I had with the stakeholders in my organization, I would've lost half of the audience the first five minutes and the second half after another five minutes. You have to find a concept that the business stakeholders relate to. Data transformation is an abstract idea. Sometimes it's not even IT people can agree on what data transformation means. So find a name that sounds good to your stakeholders and not with IT. And finally, I will say find a good partner. It's important that you trust your partner as much if not more as you trust your staff. I think that there will be times in which there is going to be a conflict of priorities, some resources shortage, funding shortage and so on. And you want to be able to say, I trust that I got the best bang for my buck and I trusted that my partner did the right thing for the organization.
Jess Carter: Thank you for listening. I'm your host, Jess Carter, and don't forget to follow the Data Driven Leadership wherever you get your podcasts. And rate and review us, letting us know how the data topics are transforming your business. We can't wait for you to join us on the next episode.
Insights delivered to your inbox