 Hi, everybody. This is Dave Vellante. We're back. This is the Cube. And we're here with Kate Parsons from EMC IT. We're here at 42 South Street at EMC's EBC. And Kate was involved in the PMO in a project last summer called Propel. Had a lot of exposure. Sanjay Mershandani was the CIO. He used to talk about it quite a bit. And Kate, you were heavily involved. We were joking off-camera. Really, you guys went live in early July. You didn't enjoy any fireworks last year. But it sounds like it went very well. So I'm glad you made it through. Yes, we made it through. So let's talk about, from a business perspective, what were the drivers to have you guys initiate Project Propel? What was it all about? Break down the project for us a little bit. Sure. I think the real business case behind the project was the fact that we had a legacy... That's okay. A legacy ERP application that was a decade old that was built to support a very different EMC. The business had grown over 10 years time and the system was no longer a fit. We also were challenged by volume growth on that platform and had some severe limitations. So the approach that we wanted to take on this was to think about, gosh, we've got to solve this burning need. But let's do it in such a way that we allow for some growth going forward. Let's assume EMC is going to change in the next decade as well. So when we implement this platform, how do we do it in such a way that we can scale and grow with EMC? So some of the key tenants were, certainly EMC technology helps from a virtualization perspective in terms of providing the growth, but then really from a business process perspective, looking to implement this in a standard way so that we don't customize the software. We can stay on the upgrade path and continue to deliver capabilities for the business. So the before situation was a lot of customization and so you had this sort of hairball of code that you were maintaining. Is that right? Yes, it is. I think actually when you consider what was customized in Oracle and the legacy systems around it, it was over 2 million lines of custom code. So the migration from the old to the new, there's got to be some risks involved in that. Talk about what those risks were, which ones you identified beforehand and how you managed those. I think some of the key risks that we were concerned about was one of the big ones was scope. So based on the timeline, the criticality of getting a solution live based on the fact that our legacy system had limitations, I think we had done some projections in 2009 that said, this thing is really going to start coming to its knees in 2012. So timing was of the essence. When you say coming to its knees, do you mean performance wise or just the ability to keep up? The system had reached severe limitations. In fact, one quarter before go live, we actually hit an integer limit in Oracle and had to start deleting tables from the database. So it was on its last legs. It was like Y2K in 2012. So I think one of the biggest risks we had to manage was how do we control scope knowing that we've got to get this new system live in July of 2012? So how did you do that? You had to break some eggs and tell some line of business guys, sorry, no, we're not going to have that function. How did you prioritize? We introduced this mantra with the project team kind of crawl, walk, run where we said the focus of the implementation is going to be to give you like for like capabilities based on what you have today. There are probably tons of areas where you can get incremental capabilities in fact that this SAP platform is now 15 years greater than the legacy Oracle one we were on but we've got to stay focused on delivering the core solution and will allow you to grow incrementally and if done in a vanilla fashion the ability to turn on those incremental capabilities will be much easier. So was the objective on day one go live to make it completely transparent essentially no change to the user experience at that point in time? Just the opposite actually. Based on the approach that we wanted to take this was more than a technology refresh so we were not looking to keep processes the same and upgrade the system because that would have required a tremendous amount of customization in SAP. There was a tremendous amount of business process change that we were driving in terms of being able to implement this in a vanilla fashion so we had 140 different training classes, we developed 8,000 users, we trained and spent months preparing the business doing simulation activities to prepare them one for the new system and how that would work but two really more importantly how their business processes would be different. Can you talk about, wow, what a project, can you talk about how you sold the lines of business and the users on those changes in the business process? Was it top down, was it stick, was it carrot combination? Talk about that a little bit. It was both. I would say the tops down, we convinced the executives of the benefit of doing this and that is those integrations in the future will be easier. When you scale into new markets we'll be able to introduce things faster. Time to market for new products should be faster. There were some inevitable carrots there that they certainly bought into. We had strong support from the tops down. We certainly had tough conversations with business units down in the ranks about things they were going to lose based on the approach we were taking but everybody in the company was on board with the bigger picture goals that it would achieve which is why we were able to be successful. I want to talk about your advice. If you had to advise CIOs going through a similar process what would be the single piece of advice or most important action item that you would suggest to that senior level IT executive? I would say it's about commitment and commitment is twofold. Commitment from the executives that we talked about and then commitment on the people that are required to make these projects successful. So we took A players from the business, put them on this project full time for three years to deliver what we needed and I think that was one of the critical components that made it successful. Same question from an organizational standpoint. What do you think the single most important organizational action that you guys took that you would advise your peers to take in a similar situation? From a program structure? Yeah, from the standpoint of the organizational issues that you had to address not the technical stuff but people you had to get involved other considerations, you mentioned training. What's the most important one or two things that you'd suggest? Constant business engagement. So I think we underestimated taking 70 business people out of the business on the project assuming we'd have the business well represented. Two and a half years later when you're going live those guys don't feel like the business people to the people in the ranks anymore. They've been on this project for two years. So one of the things I think we could have done better and will do in the future is making sure that you have tight business engagement every step of the way. They're buying off on the designs, they're buying off on the changes, they're getting their hands dirty in the system, helping us test it, helping us be part of training so that we're better prepared. So you can tell you have a lot of experience in this. I'm going to keep going. I have a couple more questions for you in that regard. What are some of the action items advice to your fellow peers? Talk to the vendors now. Of course, you know, EMC is one of your vendors, but I know from speaking to folks like Sanjay Mershandani in the past that you guys are tough on your vendors. So you got EMC in here, you got SAP, you might have some other folks. What would you advise the vendor, the supplier community to do better to make your lives easier in a project like this? Great question. One of the things that we needed our partners to do, and in some ways it was uncomfortable for them, was be honest with us. Okay, we're the customer, we're not always right. It's okay to tell us if we're wrong because if you don't and we're down a path, it's going to bite us later. I think we had a couple of examples on the project where I wish some of our partners had raised their hand to say sooner, this is not a good idea. They were trying to be good partners and collaborative and we had incented them to do that, but having the confidence to tell us, you're actually not right this time, you may want to reconsider. Doing that saves everybody, we're all in this together. Okay, my last one in this advice area is from an asset management standpoint. What did you get rid of and how did that fit into the whole business case? What kind of advice would you have around asset managing what we sometimes call GRS, getting rid of stuff? We were able to, I think, eliminate close to 70 legacy applications. We had assessed about 120 of them, some of them stayed. That was actually part of our approach as well, was to say if you've got a legacy system that's serving a purpose that doesn't seem to be accommodated in SAP, it's probably okay to keep that legacy system versus customizing in SAP, given the fact we wanted to stay on the upgrade path. But in total, based on the capabilities, we were able to eliminate 65 of our legacy applications. And the length of the project from start to finish, I mean, it's really not finished yet, but from start to go live, how long did it take? It was 27 months. So we started in April of 2010 and went live on July 5th. 27 months and roughly how many people did it involve in the core IT team? 550 people on the project at peak, of which 155 were full-time EMC employees, about half of that business, half of that IT. Wow, that's impressive. Congratulations on the success, and I really appreciate you coming on and sharing with us your experiences. Great advice for your peers. All right, folks, thanks for watching. Keep it right there. We'll right back with our next guest.