'How This Client Services Manager Stood Firm Against Compromise to Uphold High Standards'

Well, thank you for that. Let me um Dive into a time when I was, um, again in the IT services group at Science Applications International Corporation. This is the company where I um spent 14 years and Worked, as I said, in the IT group for a while, but also 7 years in the line of business. One of the projects that uh uh came up, came my way was, it was a big one. It was an enterprise upgrade to our perimeter firewalls. Are you familiar with defense, defense in depth and firewall security?

yeah, let's,

6 year old.

in a nutshell, these are the boxes that make sure the bad guys can't get into the company, good, good, good assets. They're, they're important and they're full of rules as different systems and applications that the company builds up over time are. Um, imprinted into the rule sets of these firewalls, it gets tough to manage. So here was the situation. Uh, I was the project manager set to, uh, upgrade and improve the firewalls. We did, um, uh, an analysis of alternatives, and that led us to a certain vendor. That analysis of alternatives was had a deep engineering rigor. It had weighted criteria that were agreed upon in advance. I got a bunch of engineers to look at it, and we made a good call, and we made a recommendation for a company called Palo Alto Networks. That's what we wanted to go with. But there, you know, in line with your question, there were some people who had some different perspectives about that, and one of them was the CIO of the company, Charles Beard, at the time. Charles was looking to increase um SAIC's standing in uh the defense contracting world and had met a new friend named John Chambers. John was the CEO of Cisco. So what ended up happening is, um, the Cisco solution had been our second choice, and we were directed, we were directed to use Cisco edge firewalls in our implementation rather than the Palo Alto setups that we had worked so hard to justify and, and, and defend our case for. And Uh, it was my job to take a moment and defend the analysis of alternatives against the requirements and that hard work we had done to make that decision. And I was overruled. I was overruled, but I, I felt I, uh, I made a strong case. I showed the backbone and, uh, represented the, um, the best for the project and the best approach for the company that I could. Be that as it may, the CIO made a decision and I implemented the Cisco firewalls, um. Uh, later that year.

Well, I'm, I'm passionate about uh this, this uh approach where you, you look at a set of weighted criteria, you look at different ways that you can solve a problem. First of all, be grateful that you have some options. But then, if you've been smart about what you're really looking for, you've got uh a couple of criteria that lead you to a certain, uh, a certain decision. Certainly one of those is cost. Certainly one of those is ease of transition. This is one of my favorite ones. The ease was with the company was going to bring these firewalls in and set them up and learn them, you know, even with a vendor's help, that's a factor you can weigh. Um, the costs over the life of the, uh, infrastructure that you're buying, uh, not just the cost that first year, but the operational tail going out into the out years. We factored these things together against a really long list of, of, of good technical requirements and Palo Alto just won. They were, they were on top of the market. Um, they were ahead in Gardner and Forrester, uh, reports because they were doing some things that related to um a different changing use of the internet for companies, uh, web application firewalls, and some other things that were just attractive to us at the time. So, we thought we had our stuff together and we really, um, not just for that work, but for the, um, uh, the, the spirit of the team and the rigor of engineering needed to be defended. And so that's why I stood up. Again, I was overcome by, you know, events, and that happens in project management, and that happens in, in companies, um, and I'll just uh finish off my My little scenario here by saying that the company today is still on Palo. They went back to Palo Alto Networks, uh, and have been on there ever since.

Oh, it's very possible that there were other things that the CIO was aware of that, that I was not. That's OK. That's all right. That, that, that happens. But um I, I do feel that there needed to be a moment where he understood that this decision coming from his own folks was a, was a good decision. It was a good recommendation. And for him to not go with it, uh, I have to understand that he had his reasons. That's OK.

It happened about a year later when the rules translations that I mentioned at the start um couldn't be handled. The transfer from the old firewalls into the Ciscos was, was not going well, and we decided to cut our losses. We auctioned off the appliances and bought the Palo Altos. And again, the CIO accepted it with grace. It just didn't work out. But again, it was, it was those, um, it was in the thousands of rules and bringing them over and making them work correctly on fresh new firewalls that was the downfall of the Cisco product. He saw that. why not. Yeah, I mean, the one of, one of the other learnings for me on this one, I'll just, I'll just add on if I may, is you can never underestimate the amount of of influence that external factors can have on a project. You think you have everything in a box tightly wound, well planned. Um, other things can happen outside, and that's, that's business. It is indeed.