by Elizabeth M. Ferrarini
Robert Mitchell jumped into "fire-chief mode" three weeks after he was promoted from senior director of strategic business analysis and strategic business implementation to CIO and vice president of operations at GTSI in Chantilly, Virginia. The go-live deployment of a $10 million PeopleSoft supply chain system, integrated into the company's current PeopleSoft HR system, disrupted operations at GTSI, a $1 billion provider of IT infrastructure solutions to government agencies. Because the first three months of the troubled deployment kept GTSI from delivering products and services to customers, the revenues for the publicly held company were jeopardized. Meanwhile, the company shelled out $1 million to fix the PeopleSoft problems.
Mitchell sat down with enterpriseleadership.org to discuss candidly how he perceives his leadership role, how he was able to get his arms about a negative situation, contributing factors to what went wrong, and what he learned from the experience.
EL: You moved up from senior director of strategic business analysis into the role you have now. How did all of this prepare you for the CIO role?
RM: The CIO role is about being a business leader who adds value to the company, not about being an IT project manager. Looking at it from this perspective, my past job at GTSI and my previous positions were critical to my success as a CIO. They were about understanding the strategy, understanding the financials, and understanding the business process. They were almost always about having good relationships throughout the business and being able to know who to go to.
Most people associate PeopleSoft with human resources. We use PeopleSoft for all of our internal business operations, everything from human resources to our entire supply chain. Even our sales people use PeopleSoft to generate sales quotes.
EL: Several trade press articles talked about the major operational problems you had with a PeopleSoft supply chain deployment. What went wrong?
RM: As CIO, I inherited the PeopleSoft supply chain deployment, which had been run as an isolated IT project, not as process improvement for the company. IT was unsuccessful at getting the business involved in the deployment. It slowed everyone down and certain departments ground almost to a halt. The problems ranged from training in general, to this specific implementation. In addition, we brought in too many contractors. We should've hired employees to fill functions that required passing knowledge on to other employees. We didn't think through some of the required test plans and business acceptance issues associated with it.
The momentum to go live with the system by a certain date meant no turning back. I knew it was going to be very problematic when we went live. However, I also had a clear idea of how we were going to fix the problems, and how I was going to minimize them. If I hadn't jumped in and did some of the things I did on the business side, it would taken longer than 90 days to fix the problems.
EL: What did you do first?
RM: I had to engage the business in what was going on. They needed to understand that IT is basically a set of mechanics and a custodian of the system. They had to take ownership of the system and to learn how it works for them.
On my second day on the job, I got representatives from every department in the company to come to our board room, to sit down in front of the CEO, and to give him an overview of what the system meant to them. We built a council of people, our version of a governance board, to make decisions about system changes.
We set up a war room where IT people would come and get answers immediately, and we could prioritize and enter change tickets right away. We really made sure we had a clean process for addressing the most critical issues first.
EL: Was this the most challenging IT initiative of your career?
RM: Absolutely. There was an interesting twist to it. While it was challenging on one level, I found it easy to resolve because I knew what to do. Think about it for a minute. If the executive team thinks they need to make big changes to gain efficiencies, you have tremendous amounts of resistance throughout the company. On the other hand, if a badly designed system doesn't allow people to do their job, then everyone supports changing the system.
Creating a forum of people who were willing to take responsibility for their system made the situation easier to manage.
EL: What other things did you learn?
RM: You have to deal with many aspects of change management. Specifically, you have to work through a variety of communications levels -- everything from executive, down to user community -- at the same time. You have to be very clear about who own the business process and who owns the IT automation process. Many people like to start with, "What does this system do for me?" If you don't change that attitude from the start, you're going to run into problems.
EL: As result of this experience, what formal IT best practices have you put in place, and how have you improved alignment with the business?
RM: We have a well documented, disciplined software lifecycle process. As a publicly held company, we have processes compliant with Sarbanes-Oxley. We've used many different sources to document, and to develop, these very processes.
As for alignment, we've created a synergistic environment in which the skillsets overlap between business analysts and IT functional analysts. For example, in IT, I have functional analysts with extensive PeopleSoft expertise who understand functions such as purchasing. Likewise, I have people indirectly reporting to me who manage the process and who also report to the functional department head. These people work hand-in-hand with their IT counterparts to make sure the proper implementation and requirements get done.
EL: What was your relationship like with PeopleSoft during your troubled deployment?
RM: We didn't have a good relationship with PeopleSoft at that time. Both parties were at fault. Because it was trying to fend off acquisition attempts from Oracle, PeopleSoft didn't want to have negative press about a bad deployment. I made sure we kept focused on solving the problem rather than complaining to the trade press. This strategy helped to improve our relationship and gain access to some good people within PeopleSoft.
EL: Now that PeopleSoft is part of Oracle, what is your relationship like with Oracle?
RM: Large companies, such as PeopleSoft, don't do a good job of being held accountable for what happens. You have to find a method to protect your interests. I started building relationships and getting conduits to certain Oracle vice presidents who can smooth out any problems. In turn, we've provided Oracle with architects who served on a leadership committee to define the future of PeopleSoft.
EL: Why did you eventually go public with the trouble PeopleSoft deployment?
RM: We were approached by a reporter who heard about the situation. Because we had just come through the toughest part of the deployment, we thought it would be a good chance to talk about how we got our hands around the problem. After all, we took a beating on this. Out customers had experienced negative delivery ramification. We also had to satisfy our shareholders.
EL: Undoubtedly, you've reflected on this deployment. What conclusions have you come to?
RM: Because I took over the deployment a few weeks before in went live, I had no trouble taking the high road and not pointing fingers at any one. If I had been spearheading the project right along, then everyone would have been pointing fingers at me.
Our president believes in being forthright. From the start, he acknowledged that we were having a problem with the deployment and talked openly about it. I operate the same way. I've pulled all of the skeletons out of the closet so they can be fixed. That's why it's important to leverage all the relationship you have.
--
Elizabeth M. Ferrarini is a freelance technology writer based outside of Boston, Massachusetts. Reach her at elizabethferrarini@yahoo.com.


