 The very first engagement that I had, where I started to pull IT for IT into the picture as a tool, was an unhappy customer. It was an engineering customer of ours, and we have a balance of trade situation. We use their engineering tools in manufacturing stuff that we sell to the market. So there was a bit of a balance of trade, and as a result, there's a very high level relationship between that company and HPE executives. And that was back in the 2013, is when I first saw IT for IT, and when I got the courage, and I got the knowledge, and I guess confidence to use this in an engagement, was around the end of 2013. And that was the result of an escalation, and that escalation kind of went like this. Customer bought a lot of tools, because of this dynamic between these two companies. They bought all our stuff, and they were very angry. They were at a point, so they said, we bought everything, we listened to you, your different teams, and we've integrated the best we can, we're not seeing the value from the tools that you sold us. And as a result, because this is what we did, we said, here are the tools, good luck. There was really no guidance, there was no way of explaining how everything maps together. I equate it to selling you a thousand-part puzzle without showing what the picture looks like on the cover, right? So figure it out on your own, good luck. HP's reaction was not good. There was a lot of executives that basically responded, and we started looking internally to how can we better do this, right? And IT for IT was sort of the part of my answer. The solution was, they brought myself in and Mr. Brancato, some of you folks might know him. My fellow EA culprit. And we just pulled in IT for IT at that point. It wasn't called IT for IT, I think it was still ERP for IT, we still hadn't branded it. It was not a standard yet, it wasn't in the open group yet. So it kind of predates a lot of the activity here to kind of nominate, normalize it. And engagement kind of went like this. A lot of whiteboard drawing to kind of figure out what are they using, how is it connected, kind of just diagnosing the situation. So as we went through this whiteboarding exercise and gathered information and as a result of a two day workshop, we were able to kind of categorize using IT for IT and take note of all the different tools that they had bought in the different categories and took lots of notes that we were able to go back later and sort of rationalize, what does this current state really look like? Why is it they're not getting value from what we sold them? And what is this, what's really going on? So as we went through this process, we had the data and what we ended up doing is taking all that data and just mapping it as the backdrop. I think Rick, you mentioned this earlier today too. It's the backdrop. So we just used the backdrop. This is the original, by the way, the actual IT for IT standard changed some of the namings and some of the components. So it doesn't look exactly like this now but this is the raw result from that effort. And so with that mapping, we were able to identify certain things that weren't connected right and also where things in their environment should have been removed long ago but they were still there sort of creating noise, bogging them down. And out of this came very specific recommendations. The CIO in this case was dealing with everybody asking for funding and he had no way to mediate that or to rationalize that funding request against where do I really need to spend the money? I call it that root cause analysis and where that root cause is. Don't whack the mole, let's kill the mole, right? That's the idea. And in this case, this organization had our tools, they already had them. Remember, this balance and trade, a lot of them use most of the tools that we have, gave them access to everything. They implemented a lot of these things but we didn't give them the guidance. And so based on this analysis, we were able to identify that they had all these monitoring tools connected directly to pagers. This is very tactical, mind you, right? Down in the left, right hand side of the framework. But none of them were going into their BSM system. What that resulted in is a pager storm whenever an event happened, right? A big event that had a lot of impact, hundreds of people get paged and they all responded and it was just a war room situation. But they had the tools and they just didn't use them and basically wired the tools that they had together properly. And the IT for IT framework gives you pretty clear instructions on how to do that. I equate this to an IKEA instruction set that allows you to connect things properly together so that you can get the value out of it. So this is the actual recommendation we had. We, the CIO in this case, we went through four workshops. This is kind of back in 2014 when we finally went to the EBC. We had an executive briefing at the result. It was about six months, I guess, span over those different workshops. And the customer was, as a result, well, one more view. This is interesting, because we did this repeatedly for the different value streams. And when we did this, we found out the hotspots in each value stream where the problems were occurring for that particular value stream. And what the CIO, again, it was just waiting. It's a waiting process. Where is my real biggest problem? Lowest hanging fruit. And where do they need to, oh, sorry. Where do they need to make the investments? And I'm sorry, the numbers didn't come up for some reason, but the corporate priorities, we also mapped down to each of the two value streams in this case that we evaluated. And so we were able to zero in on the one step in the value stream that had the greatest consequence and greatest value for them to invest in. In this case, it was diagnosis. When they have all these events, they can bring it to centrally and they can diagnose problems faster, get rid of the warm room situations, at least mitigate them, and increase their risk profile. And actually make that much better. Of course, you don't have to wake up 100 people, 1,000 people at night. People, only the person that needs to get woken up, gets woken up. So that was the recommendation. I gave this view to the CIO. A year later, I came back and it was still on their wall and there was penciled in dollars and people's names. A few things were scratched out, but this became his sort of high level strategic planning template for his team, which was kind of cool. Okay, so that was the story number one. The result of that really was the customer was now happy. No more escalations. The software team was able to move forward. And these are the three key value sets, right? The expectations as to how the software is all supposed to work and how IT is supposed to work was now set. There was, they had the picture on the front of the puzzle box and they knew exactly which areas of the puzzles to build next. And then they have the logical prioritization process because we found the root causes and we were able to help drive that. On our side, of course, we were able to not deal with those escalations anymore. And after we got through the pain points of where we were, we saw more business as a result. As a vendor, if you don't deliver and service what you sell, it doesn't matter who you are, what industry, people won't come back and buy if they're not happy. So we kind of turned a really negative situation into a positive situation.