How a CIO Navigated the Task of Creating Two Big Companies From One

Many CIOs have wrestled with stitching together an integrated technology platform after a corporate merger. But Robert Logan, CIO of Leidos, faced an altogether different scenario: creating the platforms, data and applications needed for two big companies born from the splitting of an even bigger company. Logan’s company was born from SAIC, a major government contractor that bifurcated in August 2013 into Leidos and a smaller SAIC — a strategic move driven by changes in the federal services marketplace.

In this installment of the IDG Enterprise CIO Interview Series, Logan spoke with Chief Content Officer John Gallant about how SAIC’s earlier efforts to build a massive private cloud environment eased the split, as well as how his team balanced the difficult preparations for creating two publicly held companies while at the same time providing services to a multibillion-dollar corporation. He talked about lessons learned and where he’s taking IT for Leidos in the future.

Logan is a member of the CIO Executive Council — IDG’s peer-based global community of leading CIOs. For more information on the council, click here.

[ Tech Titans Talk: The IDG Enterprise Interview Series ]

CIO.com: Usually when we talk with CIOs it’s about the difficult task of merging companies. But you were faced with the polar opposite: creating two big companies out of one very big company. How do you even begin the process of navigating that and providing the right technology platforms for everyone?

Logan: Let me go back to August, 2012 when we first learned we were going to be taking this 43-year-old company and doing something quite new with it. For the previous 18 months, IT had been on a path to move from our purpose-built, organically grown data center complex that had serviced the company for many years, to an enterprise private cloud using all the things you would associate with a cloud-type capability — increased virtualization, flexibility, a location that provides us a much more appropriate way of supporting the company’s future growth.

It took us about a year to build out that new complex and around six months to migrate the hundreds of applications and services that were associated in the California area to our brand new enterprise cloud data center in the Dallas-Fort Worth area. That had just concluded in June, 2012.

Two months later we were given a new assignment: take our brand new data center and, essentially, make two of them, make a copy of it. I can remember distinctly sitting around with the engineering team as soon as we got our new assignment. We had such intimacy with what we had just built. We had used best practices. There was a great deal of pride and familiarity with this new capability. Because it was a cloud-like capability using virtualization, using the kinds of things you would want an enterprise cloud be able to do, we [undertook] probably the most extreme use of it just two months after it went online.

Almost immediately we thought that the only way to meet the timeframe was to actually make almost a copy of that data center. With two publicly traded companies, we had to make sure that the systems set up for both had the same certifications and the same verifications and validations of all the requirements that they would have to meet. They would both have to support a publicly traded structure right from the start. So the driving idea was cloning, but our cloning was everything — not just the data, it was the structure and the architectural design.

We realized that to meet the extreme timelines we were going to have to use extreme virtualization. Where there was once one data center using the same space, there would now be two. And we had to operate the existing company up to the very end. That became the challenge before us. But we were very confident that we had a high-quality, best practice design. It’s just that we were going to exercise it in a manner that was at the bleeding edge of what you would ask an enterprise private cloud to do.

CIO.com: How did you structure your team, knowing you had to deal with that big change while still running the company?

Logan: I was assigned as what was called the IT functional [lead] and each corporate function had a representative in what we called the Gemini Leadership Team — Gemini being the name of the splitting program. We used the kinds of standardized processes the company is known for to do a decomposition of the scope of the IT functional lead.

Obviously, our job was not just associated with the data center activity, it also had to do with 350 sites that were going to now be split somewhere – sites that were going to go to one of the companies or the other, and some would actually be shared sites. We had to take into account all aspects of the networking layer, as well as all of the applications and uses of systems that were outside of the corporate world. As the IT functional lead, my scope of responsibilities was oversight of both the line IT activities, as well as the corporate IT activities. That was kind of our top-down approach initially.

Because of our recent work with the corporate functions and the line [operations] during the migration activities that had just occurred, we already had developed close working relationships with functional points of contact throughout the company. We used some of the common ways to scope and shape this effort and then we dove down very, very rapidly into that detailed design work. The big thing was the sequencing of not only this entire process, but the sequencing of the prep to get there, as well as the sequencing of the actual cut-over event.

CIO.com: Did you establish some key success criteria that you tracked for this process?

Logan: Absolutely. Again, drawing from the lessons that we had learned in the past we knew what long-lead items were. We knew where there could be potential challenges. So we wrapped those with a series of metrics and a series of reviews, where you come up for air. Right from the start, we established, in a different building, a whole team of folks who basically were a part of creating those kinds of structures and then they became the leadership team that drove the activities throughout the organization.

We had each functional component in the same building, which was extremely important because of the interrelationships that would be required to split this $11 billion company into two other companies. There was a whole series of reviews and sharing of how different functions were doing things, because we realized that as we moved forward the IT portion of this became something akin to glue-ware that tied the entire effort together. In many cases, whether the function was facilities or HR or finance, there was an underlying foundation of IT. That commonality of our IT relationships helped to bring the entire group together throughout the process.

One thing, John, that was interesting, was that when we had done the previous migration to the enterprise private cloud, we had the luxury of time to de-conflict activities. If we knew that various capabilities or systems might have strong interactions, we did our best to use time to space those activities out so that we would de-conflict as much as possible and reduce the risk. Gemini was different.

CIO.com: So one of the things I was specifically wondering about was the data. Some data is applicable to one company and perhaps not the other, and it may even be in the future there are some competitive situations between the companies. How did you handle that tricky aspect?

Logan: That was, right from the start, the issue. It was kind of a two-step program. We knew that we had to make good the ability to replicate the data accurately as it existed almost at the moment of the split. We knew that we had to put into place and we had to practice that — not only copies for one company, but in fact, we were still running the company at the same time. We ended up having to make two sandbox environments. We actually repurposed existing assets within our data center complex and created sandboxes where we could make the copies. That allowed the functional teams and others to begin the process of making what we called fit-for-purpose scripts.

These fit-for-purpose scripts basically were activities that various teams had to do against those data sets that started out as being cloned copies, but then were manipulated by a fit-for-purpose script that allowed them to then be appropriate for one or the other company. It could be as simple as: ‘Oh, these six contracts are used by this company and those four by the other one’.

We had to create these sandbox environments to allow them to practice and go through that process because when we actually had to do it for real, there was that aspect of time and sequencing and de-confliction. We worked from the bottom up. We would do things to practice individual items, and then over time you migrated from the individual relationships to smaller sets of systems to full services, until we had, near the end of the project itself, leading to cutover, two major dry runs where we went through the entire process in both sandboxes to replicate the activity that would be required at full split. Start with the little pieces, gain confidence, merge things and then practice for the real thing.

CIO.com: What would you say, Bob, were the trickiest aspects?

Logan: I think one of the things that was most challenging was the fact that there was no schedule flexibility. We were going to have this done by a certain time. We did not have wiggle room. That drove everything we did. It certainly provided clarity and a focus on our decision-making activity. It provided a strong bounding condition for how much time we had for certain things.

I think that weighed upon all of us: we have to do a lot of things and make sure that they are going to operate very, very well at a high degree of confidence. The other aspect is that we realized that while we’re doing all this we still have to provide the same services to our company that we’re providing right now. This constant balance of having to run the company and at the same time develop the equivalent of two companies — that balance between operations and preparations — was really hard.

CIO.com: When you were going through this process, did you also take the opportunity to look at any new capabilities?

Logan: We had just built our new data center. We had good shiny things to play with, so to speak. They were in place. So we felt like we were making a copy of something that was already good and not old. But during the process we introduced a new authentication system for Leidos, which was already planned for. We were also upgrading our email systems at the same time. In the background, while we were doing our Gemini work, we were also creating new Exchange systems for both companies. Literally, days after the separation, we began migrating those systems over.

CIO.com: What are the key lessons that you would share from this process?

Logan: I think one of the key lessons was that the ability of a team to respond rapidly to such dramatic changes was directly proportional to their familiarity with the details of our systems. If we had been asked to do this two years after we built and moved to our new enterprise private cloud data center, this would have been more difficult. Perhaps some of those unique skill sets associated with that innovative engineering and working with new things, you want to keep those rich. I’m thinking that at any point in the future if we are challenged with doing something like this, our ability to respond will be directly proportional to how familiar we are with the systems that we have, their capabilities. I think that’s a lesson that is very important from here.

CIO.com: So was it someone from within the organization that took over in a complementary role with the new company?

Logan: No. The other CIO was hired in 2013. He and his staff worked in a complementary manner during the preparation for Gemini. One of the principles throughout this whole effort was this concept of one team and one goal. At some point during the Gemini program we in IT knew which company we were going to end up in. But we knew that we were working together shoulder-to-shoulder throughout the entire process. After the split was achieved, the teams, through a Transition Service Agreement, worked in a complementary manner doing knowledge transfer.

CIO.com: I wanted to spend some time talking about what you’re focusing on going forward with the new company. What are your key initiatives?

Logan: I talked earlier about the journey to our enterprise private cloud. That included not only on-premise capabilities but also a series of Software-as-a-Service providers as well. As Leidos, we continue to look for opportunities to make better use of that hybrid cloud. We just recently awarded a contract, and we’re now moving from our on-premise human capital management system to one in the cloud. So that’s an example of some of the activities that we’re undertaking this year. One of the things that occurred with Leidos was that with our core businesses associated with national security, health and energy, we’ve looked at some opportunities for IT services and we believe that we have even more opportunities under Leidos to pursue appropriate cloud-based capabilities.

CIO.com: Your enterprise private cloud is a big and ambitious undertaking that a lot of IT shops of almost any variety are considering or actively involved in today. It seems to me that your learnings there would be very valuable in your work with your customers. Is there a way to capitalize on what you’ve learned as you work with your customer base?

Logan: Yes, absolutely. When we were building our enterprise private cloud, we used that as an opportunity to drink our own champagne. When we did the design and creation of our enterprise private cloud, we actually drew from the experts that were providing these same services and support for customers, and we incorporated them. The lead engineer and the lead [project manager], were from the line [teams] who were providing these services.

They were augmented by our own staff and we worked as a team, working side-by-side to actually design and create this capability. When that was done we had a brand new EPC that was a showcase for not only hardware-based solutions but also the techniques and the disciplined engineering approach. My hat is off to our own company because it’s the proof of the pudding. It was not just to do a 10 percent uplift on capability, but in fact to develop a clone that works just as well as the original.

CIO.com: A final question, Bob: How do you see the role of the CIO evolving? There is an awful lot of change going on in technology, in the industry, in the strategic partner base, opportunities and challenges. How do you see the role evolving and how do you see your mission evolving?

Logan: I had the pleasure of attending the [Computerworld] Premier 100 conference recently, and I heard so many good observations from fellow CIOs. One of the things that resonated with me was this exciting evolution of the CIO role where you no longer can just focus on traditional IT for the enterprise. Now you have to look more openly to a wide variety of consumer IT solutions and really think about that and incorporate that. I was very, very enthused to see that emphasis, that common theme throughout at least the Premier event.