[Interview] Part 2: Celso Mello, CIO of Chubb Security Systems
This is the next blog in the continuing series of interviews with leading professionals.
In this blog series, we talk with Celso Mello, a leading IT leader. I had the pleasure meeting Celso at the CIO and IT Executive Summit in Montreal.
Thank you and Enjoy!
Stephen Ibaraki, FCIPS, I.S.P., MVP
______________________________
Celso Mello: CIO, Chubb Security Systems shares tips about: Infrastructure, Security, Budget, Strategy, Compliance
Stephen: Celso can you expand upon your discussion in the last blog to include your challenges and tips/lessons with your work with:
Celso:
- 1. Infrastructure:
Many companies have outsourced or are considering outsourcing of IT infrastructure. While I certainly appreciate the merits of that, I think in some cases full IT infrastructure outsourcing can strip the company of its entrepreneurial spirit and speed, which can be particularly detrimental when it's a matter of competitive advantage.
For example, let's say your company wants to start doing business online, and your competitors are not quite there yet. If your infrastructure is outsourced, typical lead-times to have a simple new server deployed range from 8 to 10 weeks. As a consequence, the hardware could turn out to be the critical path task on your project plan, giving your competitors the chance to get there before you. This may be a crude example, but you can certainly apply the concept to any IT project. That's not to say infrastructure outsourcing is all that bad. In fact, things like PC refresh and helpdesk can be usually performed by an outsourcer at the same or lower cost, and with much better quality. So, if you're considering outsourcing, I would suggest you talk to your peers who have already gone through it and learn from their experience, and most importantly, take it gradually. As a matter of fact, it's no wonder that the outsourcing companies will give you a better deal if you outsource your entire infrastructure to them, as opposed to selected portions of it. - Security:
Security attacks are happening by the thousands at any given time to any corporate network these days, so I believe it is only a matter of probability that one day, one of these attacks will get through. Depending on the impact, you might be caught explaining to the press why that happened - just recently we all heard in the news about a case of a major retailer that had customer credit card information hacked. So, here are two suggestions, if you don't already have one: hire a security specialist (or a do a security assessment using an external service), then, look into deploying an Intrusion Prevention System (IPS), which can anticipate and block these threats to your network. These actions should get you covered for now, and most importantly, create a setup you can build up on or quickly adjust as threats become even more pervasive. - Budget:
Generally speaking, IT leaders have been mandated to deliver more with less money. And the reason is simple - the businesses IT supports have been required to do the same in order to stay competitive. Traditional answers to that dilemma usually involve outsourcing, sending jobs offshore, focused investment, renegotiating vendor contracts, consolidation, etc.
All of the above are very valid initiatives, but I'd like to propose an alternative method to achieve that: quality improvement. I honestly believe that any IT department can become much more productive if it undertakes a serious quality program. That's not a short-term deal, though. Think of it as a "diet" program - you might be able to get short-term results out of it, but chances are you will only be able to maintain them going forward if you've actually changed your lifestyle as a result of it. That's not a new concept, but it is very infrequently applied. I've seen real good results out of it and have become an advocate of quality in anything we do.
By the way, note that productivity improvement is only one of the benefits of a good quality program - here's another one, maybe just as important (if not more): customer satisfaction. - Strategy:
I have strong feelings on this one: I believe a good IT strategy has three key elements (and only these three):- what the business wants IT to focus on,
- what IT believes it can do to help the business, and
- how to reduce real risk to the business.
And by business I actually mean P&L. Anything outside of these parameters can arguably be done some other time. Look hard at each of your strategic IT projects and ask yourself: does this project deliver more sales, less cost, more productivity, or mitigate (real) risk? If the answer is yes, than you're probably on the right track (assuming of course the business leaders agree with that answer). If the answer is "no, but…" then you can probably leave it for later when you have spare time/resources/money (I wonder if that day will ever come…).
I recognize this sounds very basic, but it is amazing to see how frequently IT strategy includes projects that do not directly add any value to the business.
- Compliance:
This is usually an area of pain for many CIOs and I certainly have my own share of that. But as you try to understand the rationale behind these regulations, for the most part, you'll find out they're rooted in good practices. Unfortunately, probably due to the context and expediency in which these new regulations had to be implemented it all ended up looking like unnecessary bureaucracy and additional work, but if you look through that and find a way to incorporate it into your daily routine without adding too much overhead, you can actually use it to your benefit.
Let me give an example: one of the IT controls attributed to the Sarbanes-Oxley Act has to do with having a Change Control process in place, which includes the need for properly authorized written business requirements. Well, once you implement this, you will no longer have to deal with that user who every now and then would go directly to the programmer and ask for a "small" change done to the application, which may end up tying up your resource for several weeks, causing delays to another project that resource was supposed to be working on. With this, you can simply say "no" to that user, no matter how high in the hierarchy he/she is, until he/she comes up with written specifications, and this all in the name of Sarbanes-Oxley. This example may be oversimplifying the issue, but I believe it will get the point across.
________________________
Look for more with Celso in the next blog.
I also encourage you to share your thoughts here on these interviews or send me an e-mail at sibaraki@cips.ca.
________________________