'Tis the season for all of those year-end wrap-ups you see in just about every publication under the sun. I've done my share of those at past gigs but have struggled to do so at IT Business Edge because of the broad spectrum of topics I cover as part of my "Business of Technology" beat. If it's under the purview of the CIO-and sheesh, what isn't-I've probably written about it.
This year, I'd thought I'd share some snippets of the discussions I've had with smart CIOs as part of a "CIO Conversations" series of interviews. The idea for the series-which I plan to continue in 2011-is to speak with technology executives employed across a broad swathe of industries about the opportunities and challenges of their jobs. The industries represented included health care, education, government agency, nonprofit and financial services.
To keep my posts readable (translation: fairly short), I'm making this a two-parter, beginning with the CIOs I've interviewed most recently and working my way backward.
When I asked George Tumas, executive vice president and CIO for Wells Fargo's Internet Services Group, about how his company was seemingly sailing through integrating Wachovia Corp., which it bought in December 2008, into its business, he said:
The key to our successful integration has been all the planning we did upfront with our business and technology partners. We meet on a regular basis. If we weren't well-connected and didn't meet on a regular basis, I don't know if we would have been this successful.
Our biggest challenge is keeping both old mainframe technology, which has done us well for years and will for years to come, as well as client server technology in mind when we build applications. We're not like Google. We have to deal with new, sexy stuff as well as legacy technologies.
When I asked Tumas about agile software development, I discovered he wasn't a big fan:
'Agile' sounds really sexy, but it lacks documentation. When we're doing a project that involves middleware and mainframe components, you really need good, solid documentation. The last thing you want to do is put an application out there that doesn't work for our customers. They'll find a new application online as soon as it gets deployed. You can use some pieces of agile, but quite honestly we shy away from a lot of it because of the lack of documentation.
When I interviewed Sean Poccia, director of Information Services for Comag Marketing Group, I asked him if boosting productivity of his company's large field staff was the primary reason for launching an ambitious mobile technology program. Sure, he told me, but it wasn't the only reason:
There's also a need to maintain a competitive advantage in the marketplace. We treated the recession not necessarily as a venue to hold back investment. We looked at it as an opportunity to do the tortoise-and-the-hare trick, where we can surpass our competition. You have both the tactical side and the strategic approach to mobility.
An often-neglected aspect of mobility programs, Poccia said, was the need for effective support:
Here's the No. 1 aspect of a successful mobility program: If you're going to ask somebody to embrace real-time interaction with an application, you better be able to provide real-time support. With mobility, we get so excited with the new shiny toys and we do a great job with development and deployment, but then we forget about the ongoing support. If you don't modify the support program to mimic the general expectations for the mobility program, it won't work. That's where a lot of companies fail. If you've got a guy sitting in a store connected over broadband and the application fails and the guy leaves the store without entering his data, you've had a failure.
His team is all about speed when it comes to delivering new functionality, Poccia told me:
We survey our work force monthly and create a venue to allow every employee to provide feedback around the user experience, anything they feel can help them do their jobs better. We take those ideas, vet them very quickly, take the ones we feel have real merit and get them to senior management. We bring them to fruition as quickly as possible. It instills a sense of ownership in our employees, when they can see their suggestions come to market that quickly. It helps us promote a continuous improvement culture. Many organizations store up ideas and batch them in six-month releases. We do it monthly. We're an IT team of 25, and we are constantly doing sprints.
When I interviewed Tim Kobosko, vice president and CIO for the USO, he told me a big challenge was introducing more standardization:
I'm trying to scale up and drive the cost down. My mantra is standardize and scale. We have a lot of ad-hoc solutions, so we need more standardization. By some counts, we have 40,000 volunteers that help the USO. If we want to start supporting these folks, we've also got to always think about scale. With scale, we can lower the unit cost. I don't want to use a chargeback model. I tell my boss, if we can do it right, we can give IT services away. The benefits of freeing up these people's time is worth the cost. The incremental costs of adding five or 10 users should be minimal.
Kobosko also spoke about the importance of helping IT staff feel more connected to business initiatives:
The thing I am most proud of in this short time is how we've really coalesced as an IT team. It's important for my team to understand the business we're in. This was a very reactive job when I got here. 'Here's a fire that I need to put out.' So I am trying to change the mind set to one where we understand the business we are in. So maybe we go on a field trip and see goodness being delivered to troops. I think the IT staff had become somewhat detached from the mission. I spend most of the time in staff meetings not talking about day-to-day stuff but about the bigger-picture stuff like Operation Enduring Care (a fundraising drive). We even go through the annual report so everybody understands what we are doing.