Celso Mello: Chief Information Officer, Chubb Security Systems

This week, Stephen Ibaraki, FCIPS, I.S.P., DF/NPA, MVP, CNP has an exclusive interview with Celso Mello.

Celso Mello was born in São Paulo, Brazil, to a family originating in Italy. Mr. Mello also spent part of his life in Switzerland, the U.S. and finally immigrated to Canada in 2004. He has a Technical degree in Computer Science, a B.S. in Mathematics, a M.B.A. with concentration in International Business and a post-graduate Advanced Business Certification in Information Technology. Mr. Mello is a Beta Gamma Sigma member and speaks 4 languages.

Mr. Mello began his career in Brazil in 1987 as a computer programmer for one of the world's largest telecommunications companies, and worked his way up to systems analyst and system manager. He then joined a software development company where he headed up the development of a complex computer system for one of their key customers, a large elevator manufacturing/service multinational company. As part of that project, Mr. Mello personally carried out the implementation of that system at business units located in more than 20 countries around the globe. He eventually became an employee of that elevator company as Global IT project manager, after spending a year working for SAP, a leading ERP software company. In May of 2004 Celso was transferred to another division of that company, headquartered in Mississauga, Canada, as CIO for North America. Currently, Mr. Mello heads up a team of approximately 20 professionals and his responsibilities include all aspects of IT, ranging from infrastructure to applications to security, and span from budget to strategy to compliance.

Mr. Mello's achievements throughout his professional career include data centre consolidations, network upgrades, security enhancements, large application implementations. In particular, over the past 18 months, Mr. Mello's team has successfully implemented a MPLS network, a VoIP-enabled national phone system, a 1000-user Active Directory rollout, and upgraded a business critical application system, running on a 24x7 high-availability environment.

Mr. Mello is married, has two young daughters and lives in Oakville, Ontario. In his free time, he is an avid Tennis player and takes home improvement as a "serious hobby".

The latest blog on the interview can be found in the IT Managers Connection (IMC) forum where you can provide your comments in an interactive dialogue.
http://blogs.technet.com/cdnitmanagers/

Index and links to Questions
Q1		Can you describe your current role with Chubb Security Systems and how you will shape the company's strategies and objectives into the future? "In that capacity, my role is essentially about making sure there is perfect alignment between business goals and IT initiatives,( and that actually leads into the second part of your question), as the company sets its goals for the future, a well-aligned IT strategy can play a key role in assisting with them....."
Q2		What suggestions would you make to other managers to save them time and prevent the pain you may have experienced in your projects? What specific challenges/barriers did you experience and the resulting lessons and useful tips from your implementation of: MPLS network, VoIP-national phone system, 1000-user Active Directory, High-availability upgrade of your business critical application system?
Q3		Can you expand upon the last question to include your challenges and tips/lessons with your work with: Infrastructure, Security, Budget, Strategy, Compliance?
Q4		We are at the start of 2007 which provides a unique opportunity to make predictions. What do you see as the major technology roadmap trends for 2007 and in five years? "Predictions are always risky to make, but I think I can give you 3 significant trends I'm seeing right now, which I believe will change our IT world in the next few years:...some sort of a return to the 'mainframe days'.....soon be a day where IPSs will be as common as anti-viruses....businesses in general have just scratched the surface on the capabilities of mobile devices....."
Q5		As CIO, what are your leadership and management issues and how do you look to resolve them? "Here are a few that I would highlight:.......Cost-cutting / headcount-reduction pressures....Outsourcing / Offshoring trend....Creating a service-oriented (as opposed to technology-oriented) organisation....Relationship IT x Business....Multiple priorities...."
Q6		Looking back over your career, what three stories and resulting lessons can you share that were most pivotal? "I believe communication is a key piece in everything we do, so I selected three stories around that theme...."
Q7		If you were conducting this interview, what questions would you ask, and then what would be your answers? "....What are the critical success factors for IT........"

DISCUSSION:

Opening Comment: Celso, with your impressive background in the IT field, we are fortunate to have you doing this interview. Thank you for taking the time to share with our audience.

A: It's my pleasure, Stephen. I am a great enthusiast of this blog and CIPS, just to name a few of the outstanding initiatives you're associated with, so it is really an honour for me to have been invited to this interview.

Q1: Can you describe your current role with Chubb Security Systems and how you will shape the company's strategies and objectives into the future?

A: I am a direct report to the General Manager of Chubb Security Systems, and as such, part of the senior management team of that company. In that capacity, my role is essentially about making sure there is perfect alignment between business goals and IT initiatives, and that actually leads into the second part of your question - as the company sets its goals for the future, a well-aligned IT strategy can play a key role in assisting with them. For example, our company has aggressive goals around profitability improvement over the next couple of years, so my 3-year IT roadmap contains a couple of automation initiatives that will significantly improve employee productivity. This "strategy collaboration" also occurs in the opposite direction: for example, IT has identified opportunities for new products/services the business can provide to its customers through minor changes to our people/process/technology environment, and these have been added to the company's strategy as well.

Q2 & A: Please take a moment to wear your consulting hat as an advisor to other managers who are considering similar projects like the ones you have undertaken. What suggestions would you make to them to save them time and prevent the pain you may have experienced in your projects? What specific challenges/barriers did you experience and the resulting lessons and useful tips from your implementation of:

A:

1. MPLS network:
   
   Due to the nature of our business (electronic security), network availability is critical to our operations on a 24x7 basis. Downtime is not an option for us. However, any major network change, such an upgrade to MPLS we undertook, is very likely to cause downtime. To mitigate that I recommend having redundancy for your critical network traffic during the transition and stabilisation phases. In our case, we had as many as 3 levels of redundancy.
   
   The other important lesson I learned from this project is spending enough time upfront on negotiating your Service Level Agreements (SLAs) with your telecom provider. Make sure you understand how site availability (or uptime) will be calculated, the impact of maintenance windows to uptime, what Class-of-Service (COS) and Mean-time-to-repair (MTTR) are; but most importantly, establish right from the start SLAs that will meet your requirements.
   
   A final word of advice: upgrading your network is NOT a turn-key project completely performed by the telecom company - you'll definitely need your best network/security person driving it.
   
   
2. VoIP-national phone system:
   
   This was a great project and there are good cost savings that can be drawn from it. But to specifically talk about barriers, the single most important issue we had goes back to the network component: it is called Quality-of-Service (QoS). In order for VoIP to work well, you definitely need the ability to configure QoS on your network, which is essentially about dedicating a fraction of your bandwidth exclusively to the voice traffic. Depending on the type and complexity of your network, you may not be able to properly configure QoS, or you may be forced to allocate too much bandwidth to it, impacting other types of critical network traffic, such as email or application-based. So, in summary, before you embark on a VoIP project, I would suggest you understand your ability to properly implement QoS.
   
   
3. 1000-user Active Directory:
   
   The main barrier with this project was in the area of change management. Over the years, users tend to build their own setups and workarounds to overcome constraints, or sometimes they're given more rights than they need in order to perform their job functions, and they get used to that.
   
   First you need to bring it down to a level playing field and that requires a lot of internal communication and justification, or in other words, internal "selling". So, I thought about giving something in return to those users in order to achieve my objective: I had some of my best IT technicians travel to every remote branch and as they did the necessary setup on each PC to convert it to Active Directory (AD), they offered to solve any other PC-related matters those users might have. It may not sound as a fair trade, but it works much better than if you simply impose the change.
   
   Once you deal with the change management issues, you'll find the effort and investment well worth it, because AD gives you a logical network environment that is much easier to control and maintain, which greatly helps with your compliance efforts.
   
   
4. High-availability upgrade of your business critical application system:
   
   Every application implementation or upgrade is a bit different, so I'd like to focus on the high-availability aspect of this to talk about barriers. Because this particular application has a no-downtime nature (very much like our network), it was critical that the new version of the system we were upgrading to had the same level of reliability as the old one.
   
   To determine that, we used automated tools that simulated transactions and users on the system, starting from our peak historical volume and going up from there to identify bottlenecks. After addressing as many bottlenecks as practical/cost-effective, we arrived at a configuration we're confident that will handle our maximum historical load many times over. This is reassuring when you think a transaction "surge" could actually happen gradually as a result of great company growth (which we hope for), or abruptly due to a natural disaster (which we obviously don't hope for). Either way, now we know we're prepared.
   
   So, the lesson here was the value of "stress testing", which can reveal system bottlenecks which you can easily address if identified early on, allow you to properly size your hardware and give you "peace-of-mind" that the system will accommodate growth or unforeseen events. Note this applies even if you're not implementing a high-availability system.

Q3 & A: Celso can you expand upon the last question to include your challenges and tips/lessons with your work with:

A:

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.
   
   
2. 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.
   
   
3. 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.
   
   
4. Strategy:
   
   I have strong feelings on this one: I believe a good IT strategy has three key elements (and only these three):
   
   
   1. what the business wants IT to focus on,
   2. what IT believes it can do to help the business, and
   3. 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 recognise 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.
   
   
5. 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 authorised 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.

Q4: We are at the start of 2007 which provides a unique opportunity to make predictions. What do you see as the major technology roadmap trends for 2007 and in five years?

A: Predictions are always risky to make, but I think I can give you 3 significant trends I'm seeing right now, which I believe will change our IT world in the next few years:

1. Many of us are already involved or have already completed a server virtualisation project, but there is still a lot of opportunity out there on that. There are significant cost savings in these projects, and many other benefits too. I think this will evolve into some sort of a return to the "mainframe days", where you had one massive piece of hardware running multiple logical partitions operating independently, as opposed to lots of small distributed computing environments like we have today.
   
   
2. As I said earlier, I think we will start to hear more and more about security breaches, theft of critical information, denial of service, etc. All companies, not only the large ones like today, will need an information security specialist and security strategy/policies, which would include at least an Intrusion Prevention System (IPS). I believe there will soon be a day where IPSs will be as common as anti-viruses.
   
   
3. I think businesses in general have just scratched the surface on the capabilities of mobile devices. I believe in the next few years we'll see people using their mobile devices to do everything they normally would on their home or office PC, as the performance and connectivity on those devices catches up. And business and pleasure will completely come together through those mobile devices. I believe business will have to readjust their strategy in order to gear for the strictly mobile user, such as they did when the Internet became a sales channel. Also, business will be able to use the benefits of those devices internally, to facilitate things like telecommuting or field force management.

Q5: As CIO, what are your top leadership and management issues and how do you look to resolve them?

A: Here are a few that I would highlight:

• Cost-cutting/headcount-reduction pressures, (at the same time you're dealing with complex and aggressive projects):
  
  I believe I've addressed that when I talked about challenges/tips/lessons on "budget" earlier, but to recap, my approach here goes through quality improvement, as means to get more productivity.
  
  
• Outsourcing/Offshoring trend:
  
  Again, I already touched upon that when I talked about Infrastructure earlier, but essentially, I'm in favour of "selective" outsourcing in areas where you can get higher quality at same or lower cost.
  
  
• Creating a service-oriented organisation (as opposed to technology-oriented):
  
  This is a bit tricky, because IT people are naturally more attracted to technology over anything else, and typically do not have that customer-focused mentality. Changing this would probably involve DNA-reconstruction, but all kidding aside, you can get some improvement on this with proper training and coaching to your team.
  
  
• Relationship IT x Business:
  
  I talked about the importance of strategic alignment earlier, but at lower levels, this relationship is defined in terms of teamwork and ownership. The issue here is that sometimes business and IT people act as "us and them", and that becomes a game of placing blame for everything that goes wrong. That of course does not help anyone or the company, for that matter. Like other issues I'm pointing out here, I don't think there is a "silver bullet" for it, but you may get some improvement here by focusing on the service-oriented organisation I mentioned earlier, which has the potential of changing the perception business users have of IT, creating trust and team spirit.
  
  
• Multiple priorities:
  
  I'm sure many of your readers who run IT shops can quickly think of at least 3 simultaneous initiatives they're currently dealing with, all of which have the highest priority, scarce resources and aggressive deadlines. Once again, there is no easy solution for this, but you can mitigate it by having good people in your team with good problem-solving and project management skills, who could supervise external contractors if necessary (offshore contractors are very cost-effective and work well in "self-contained" cases like new application development projects for example).

Q6: Looking back over your career, what three stories and resulting lessons can you share that were most pivotal?

A: I believe communication is a key piece in everything we do, so I selected 3 stories around that theme:

1. In one of my previous jobs, I was assigned to a project where a new application system was being implemented at multiple branches around the World of a large multinational company. I was dealing with very different cultures and behaviours, particularly when it came to train users. Language was a bit of a barrier in some cases too.
   
   In the beginning, I was very focused on completing the tasks efficiently within the allocated time. For example, no matter what happened, I would be sure to complete all 12 modules of the training program in the 2 days allocated for it. However, through post-implementation follow-ups, it became clear to me that the user retention of the information they were getting was minimal and as a result there were lots of problems. In many cases, users would even find a way to go back to their old system and just "pretend" they were using the new application to satisfy the corporate office, which I was representing in that case.
   
   Then one day, I switched the approach - instead of doing traditional "classroom" training, I simply asked users to read the first module of the training program on their own, encouraging them to discuss it amongst themselves in their own language, and then try it out (on their own) on the computer sitting in front of them. Meanwhile, I would be walking around and whenever a user called me, I would assist him/her on an individual basis. Needless to say, only a fraction of the training program would get completed within the allocated timeframe, but at the end of the day, the users figured out the rest on their own, and the implementations were much more effective in those cases.
   
   The point here is not one of how to do training - rather, how to deal with people. In anything you do, people are at heart of it. I strongly believe that if you make every effort to communicate with them at their preferred method and pace, you will get their buy-in early on and as a result they will sort out the issues, and your initiative will succeed.
   
   
2. A few years ago I was associated with an application re-hosting project that would affect almost 2,000 users spread throughout the US. The project was quite complex and posed several technical challenges, but these technical issues were dealt with appropriately and timely.
   
   However, the user communication/training plan was sort of "make-shift", (it was not considered critical at the time because the impact to the users was minimal), the appearance of the system was identical to the end user - they just had to start it up from a different location. Because the communication plan wasn't great, the information about that (small) change didn't get through to all users, (or is some cases it was incomplete or inaccurate), which caused frustration and a negative reaction. By not knowing exactly what the change entailed, users tended to resist it and influenced other users to do the same. I had a very competent technical team in place that had spent weeks thoroughly testing the application and anticipating any potential issues. Also, the new application actually performed faster than the old one, but none of that mattered at that point - it was all about user perception.
   
   Fortunately, in the end we were able to reverse the situation, but this whole experience taught me that a change management plan is as important as a development or testing plan, in any IT project.
   
   
3. Finally, this last story took place almost 20 years ago now. It was about a more close form of communication, between me and my manager at the time, but there is a good lesson around open communication here: I was working for this company as a programmer for a couple of years, and was very happy with that job. One day, my boss comes to me and asks: "What are your career aspirations?" Looking at my puzzled face, he goes on: "You can do bigger and better things, but you cannot just sit and wait - you have to make it happen".
   
   Note that this person had nothing to gain by saying this to me, as he would potentially lose a (presumably good) employee. And maybe for that reason, the message was so strong and effective. To this day, those words resonate in my mind: "you cannot just sit and wait - you have to make it happen".

Q7: If you were conducting this interview, what 3 questions would you ask, and then what would be your answers?

A: I actually found this interview to be very comprehensive, but I will offer one additional question anyway: "What are the critical success factors for IT?" My answer to it is: "having good people". I honestly believe that a good team can overcome almost all obstacles that present themselves and deliver quality work even under tight circumstances. I recognise that a truly good team is very hard to find, though.

Closing Comment: Celso, again, thank you for sharing your deep insights, talent and experiences with our audience.

A: This is an honour and a pleasure for me, Stephen. I hope your readers will find some value in my answers. If there is ever anything else I can do to contribute with any of your initiatives, please do not hesitate to contact me.