mercredi 12 février 2014

10 mistakes CIOs should not make

A lire sur: http://www.techrepublic.com/blog/10-things/10-mistakes-cios-should-not-make/#ftag=RSS56d97e7

By  in 10 ThingsNovember 6, 2013, 7:00 AM PST

The CIO is a difficult job to pull off, but don't make it even harder by making these mistakes. Here are 10 things to watch out for. 
CIO image.jpg
 There is probably no more difficult C-level position in any company than that of the CIO. So much can go wrong with technology projects, and also with enterprise acceptance of them. One area CIOs think about, especially when work is not going well, is what they could have done differently. There is natural tendency to “step in” to make everything “right.” But before you do that, think again. Here are ten things CIOs should avoid!

1. Answering technology’s “siren call”

Most CIOs come from technical backgrounds, so it is natural for them to want to engage at detailed levels with technology. However, the CIO job demands that you know the technologies at a general and strategic level, but that you distance yourself from the finer details that you have staff for. If a CIO fails to do this, he can risk doing both the business and his staff a disservice. The business wants a CIO who can direct technology to solve business problems. It doesn’t care if the CIO knows C++.

2. Micro-managing

After a few years in a corner office, many CIOs get the “itch” to return to IT practice. Some actually get out into the department to where they begin to micro-manage their managers instead of mentoring them so these same managers can manage projects on their own. If you find yourself wanting to do this, resist. Your proper role should be to support your managers and to do enough “walking around” and observing to ensure that work stays on course—not to step in and run things.

3. Avoiding company politics

This is a natural mistake that many CIOs make. They think that because they made their marks in technology that they don’t have to worry about corporate politics and influencers. Wrong. Politics can either destroy projects or make them succeed. Your staff is depending on you to know which way the wind is blowing, and to create the necessary political environment within the company so IT projects can succeed.

4. Underestimating the importance of the end user experience

Because CIOs are comfortable with technology, they tend to focus on the major technical elements of projects that applications depend on in order to run properly. Among these underlying elements are database structures, operating systems, network performance, etc. However, all of these elements can run optimally and the application can still fail if the user interface to the application and the end user experience (EUE) aren’t well designed. CIOs tend to underestimate the significance of these. They can avoid embarrassing EUE failures by employing IT staff who are skilled with working with users and the “human factors” elements of application design.

5. Staying in the office

Just as there are CIOs who get the itch to run projects again, there are also CIOs who get too comfortable staying within the confines of their own offices. Never assume that what project status in a project management report tells you is 100 percent accurate. The best way to assure that work stays on course in IT is to get out on the floor, building your rapport with both staff and managers. Much can be learned about project status by observing body language as well as by talking with others. It is usually in these communications exchanges that project issues are first uncovered—before they ever show up in a project status report.

6. Being a control freak

IT-ers by nature are control-oriented. CIOs share this trait. If you are to develop managers who can capably drive their projects to success, or foster trust-inspired relationships with end users and their managers, you might find that you have to “let go.” Many CIOs want to seize control in technology projects, especially if they have experience in similar projects (and they often do). The better path is to demonstrate a little patience and forbearance. Allow others to participate and to contribute their ideas.

7. Avoiding the “dirty work”

IT pros look to their CIOs to create positive situations for their projects. Of course, there are always occasions when projects (and people) go wrong. Sometimes, it becomes necessary to pull the plug on a project, or to reschedule it. Worse yet, you might have to fire someone. Often, it is rightfully the project manager’s responsibility to do this—but if the situation is unusually sensitive, it could also warrant the CIO stepping in. Intuitively, IT staff knows when the CIO should be taking the lead. When they see their CIO stay in his corner office, letting a key manager “take the hit” for a project or personnel issue that was beyond that manager’s ability to control, their faith in their CIO is undermined.

8. Showing fierce brand loyalty

Most CIOs have careers that have spanned at least ten years, if not decades. Over this time, it is easy to forge fierce “brand loyalties” and to maintain relationships with tried and proven vendors you have known through the years. CIOs should be encouraged to do this, because IT is difficult enough, and having dependable vendors is a great advantage. At the same time, however, CIOs must be careful not to become biased against new solutions (or providers) that could also bring value to IT.

9. De-emphasizing QA

A large part of application and system success depends on how well applications and systems have been tested. This testing should be done on unit and integration levels of testing, on end user experience levels, and also on regression testing and stress testing. Since many CIOs have come from the application development side of the house, there is an inherent impatience with disciplines like quality assurance (QA), which are charged with system and application testing. Consequently, project timelines tend to emphasize application development times, but shorten the timeframes needed to do a thorough QA. Resist the tendency to structure projects like this. Give both the time and your ongoing support to your QA staff. You will be richly rewarded with applications and systems that work right the first time.

10. Not revising IT reward structures

Although many IT fundamentals and measures of excellence have remained constant, some have changed. More is expected today on getting the end user experience right, on delivering an IT service culture, and on being customer-centric in everything you do. Disciplines within IT that formerly lacked credibility and CIO support include training, quality assurance, the human-factors engineering side of application design, and the service response of the help desk. These same areas are now coming to the forefront of IT SLAs (service level agreements) that focus on service and quality. It is not enough to just activate these SLAs by measuring performance. For IT staff, money and advancement opportunities count. If an excellent QA person, or a trainer, or a human factors analyst doesn’t have career advancement or salary opportunities within their disciplines, they will either leave or opt to move into traditional “high reward” areas like application development or database. CIOs should avoid the temptation to stick with status quo reward and promotion structures in IT, because the status quo has changed.

Aucun commentaire:

Enregistrer un commentaire